Update dependencies with evidence

A small update changes one lockfile region, passes the consumer fixture, and does not add an unexpected install script. That contrast gives us something useful to test instead of a rule to memorize.

Dependency updates are code changes from another trust boundary and deserve proportionate review. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can merge a large automated batch because every version number is newer and still get one successful demo. Push past the demo. update in reviewable groups, inspect the graph and package metadata, run the full gate, and record why the change is safe, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Maintain the package as a promise to consumers, with explicit support, measured changes, and a retirement path. Save the before-and-after evidence now; it will make the final project review much more honest.

Compare the dependency tree before and after one update and explain every new package and lifecycle script. Save the evidence, then explain which requirement would force you to choose a different design.