Upgrade dependencies after refactor integration

[metaphorics]

Question

After the offensive refactor is integrated, run the repository's dependency-upgrade campaign without mixing it with feature or API-break work. Inventory manifests and lockfiles, scan outdated and vulnerable direct and transitive dependencies, classify every candidate as patch, minor, or major, and use the dated grounded release set as the version authority. Upgrade patches as one atomic bin, minors as one atomic bin after reading each changelog, and majors one at a time after reading the migration guide and propagating every API break. Keep the lockfile exact, inspect transitive churn with difft, run the required verifier after each bin, then re-scan vulnerabilities and licenses.

Do not suppress deprecations, force an audit rewrite, float versions, or combine dependency changes with the refactor. This task stays blocked while the feature tree and public boundaries are changing.

Blocked by

• Ground every repository release pin
• Integrate every refactor target

[metaphorics]

Research-owner context

Source: .outline/research/docs-rules-build-audit.md (DRB-10 :200, D17 :103, deletion-blocker row :170, boundary row :133, rule row :122).

Rows this ticket already owns (execution slice):

• DRB-10 (:200) — if the grounded set moves Lean/Racket, the upgrade runs through G1 plus all affected generated receipts/checks; compatibility and full formal gate regeneration are the blocker, satisfied per-bin.
• D17 purge class (:103) — generated/authority-owned: upgrade requires receipts, never a prose or hand edit of formal/toolchains.toml outputs.
• :170 — G1 receipts, compatibility evidence, and regenerated outputs must move together.

Missing decision inputs:

1. Boundary row :133 — lockfiles and manifests are generated carriers with named writers; every bin must regenerate through the owning tool (keeping difft churn inspectable), never hand-edit bytes.
2. Rule row :122 — release stays blocked while gates are open: no tag/publication between bins; the required verifier result per bin is the only gate authority.
3. Sequencing guard: bumping dependencies owned by the unresolved dual perf authority (D13 :99) must not implicitly resolve DRB-8; if a bump forces the choice, stop the bin and record it for the DRB-8 child instead of deciding it inside the upgrade.