dependency-upgradelisted

Upgrades fail when they are done all at once and diagnosed all at once. The discipline is: know what changed, change one thing, run the tests, commit, repeat. A day of small green steps beats a week of bisecting a red branch. ## Step 1: inventory - `npm outdated` / `pnpm outdated` / `pip list --outdated` / `cargo outdated` / `go list -m -u all`, plus the audit: `npm audit`, `pip-audit`, `cargo audit`, `govulncheck`. - For each candidate: current, latest, is it a major bump, does an advisory apply, is the current version EOL, does it block another upgrade (e.g. the test runner must move before the framework can). - Classify: **security** (do first, minimal version that fixes), **blocking** (needed for another upgrade), **major** (needs reading), **minor/patch** (batchable). Write the plan as a table before touching anything; get agreement if the list is long or a major touches the framework. ## Step 2: prepare - Green baseline: full test suite, typecheck, lint, and build pass on the current commit; record timings. - A branch per major upgrade; one branch for the minor/patch batch. - Read, for each major: the release notes for every skipped major, the migration guide, the codemods offered, and the peer dependency changes. Note breaking changes that touch this codebase (grep for the removed APIs). ## Step 3: minor and patch batch Update them together (`pnpm update` within ranges, `pip install -U` for the batch), run the gate, commit as one change. If it goes red, bisect t