refactor(graph): stop hashing the generation id into the code-graph namespace so heads supersede

[ScriptedAlchemy]

Context

Root-cause lane for the live-daemon memory bloat (PR #707 branch, issues #799 / #830):
code_graph_namespace(code_shard_id, generation_id) (runtime-core store_runtime/registry/graph.rs)
hashes the generation id into the graph-db namespace. Every published code generation therefore
becomes the permanent verified head of its own single-generation projection:

• retire_replay refuses with CurrentVerifiedHead for every generation (it is never superseded),
• retire_one_code_generation_replay blanket-retained until bc918144b/5d8fee38a (slice 1),
• the shared staging Grafeo container (proj_*/tracedecay.grafeo, 15 GB live) accumulated the rows of
  13 generations, and Grafeo's LpgStore is heap-resident, so every open replayed all of it into RAM.

Slices 1–2 on #707 fix the symptom inside the current layout (dead heads retire; staging rows of a
sealed, installed, dependency-free generation are released after seal-install; retention never lazily
opens the staging engine). They leave the layout itself in place.

Proposed follow-up

Make the namespace generation-agnostic (per shard) so publishing generation N+1 supersedes N as an
ordinary projection-head replacement, and the existing superseded-head retirement path, CAS on the
projection head, and dependency semantics apply without per-generation special cases.

Why not in #707

• Live persisted format: every existing container already has per-generation namespaces and sealed
  stores keyed by them; a cutover needs a migration or a typed ResetRequired → republish transition for
  every registered project, not a branch-local change.
• Blast radius spans runtime-core (namespace derivation), store-runtime (code graph runtime, dependency
  locators), graph-db (publication CAS now conflicting between concurrent generations of one shard —
  desired, but a behaviour change), and the sealed-store identity.
• Slice 2 + the retention fix already collapse the retained footprint; the deeper change is a structural
  simplification, not required for the memory fix. It should land as its own delivery slice with its own
  migration evidence.

Acceptance

• Publishing a new code generation for a shard supersedes the previous head; the previous generation is
  retired through the normal superseded-head path (no CurrentVerifiedHead refusals in the release queue).
• Existing per-generation containers migrate or republish through a typed state; no silent fallback.
• Delete the per-generation special-casing that slices 1–2 had to add (sealed_only retention sweep for
  legacy heads, blanket-head tombstones) once no live store needs it.

[ScriptedAlchemy]

Remote-branch audit at 298424812 (2026-09-04): c88fe1b17 + 9a805e776 now derive new code-graph namespaces from the shard alone (code-shard:<digest>), and linked_worktree_code_scopes_share_one_project_graph_lease asserts successive generations share that namespace; verified_generation_contract/code_graph_layout.rs covers canonical/legacy classification.

Keeping #836 open: the landed commits explicitly retain retire_verified_head_replay and the sealed_only retention lane to drain pre-cutover per-generation stores, and no remote evidence yet proves all persisted legacy containers are drained or that those compatibility paths can be deleted. This is partial progress, not closure.

[ScriptedAlchemy]

Landed on the #707 branch: c88fe1b17 refactor(graph-db): own the per-shard code-graph namespace and 9a805e776 refactor(runtime-core): make the code-graph namespace per shard.

Canonical namespace is now code-shard:<sha256("tracedecay.code-graph.shard.v2", code_shard_id)> (one module in graph-db, consumed by runtime-core); the retired code-scope: prefix is the migration discriminator, decided by inspection. Generation N+1 supersedes N through the existing head CAS with no new code; N becomes historical replay reclaimed by ordinary retire_replay. An upgraded store's canonical projection has no head, so recover_verified_head answers a typed Unavailable and the scheduler republishes into the canonical projection; legacy code-scope: heads drain through the retained retire_verified_head_replay path and emit graph_legacy_code_graph_projection_retired. Tests: second_generation_supersedes_the_head_and_the_first_retires_without_head_retirement, a_store_persisted_under_the_legacy_layout_opens_and_drains_its_per_generation_head, plus namespace unit tests; graph-db contract 47/47, code-index-retention 68/68, runtime-core clippy clean.

Live effect on the operator daemon: with this and the codec/memory commits installed, this repo re-indexed to ready in ~9 minutes at 4.5-6.7 GB RSS instead of stalling over 20 GB. Remaining (gated by the issue itself): delete retire_verified_head_replay and the sealed_only lane once no live store carries code-scope: rows. One consequence to watch: recover_verified_snapshot_from_head now returns a typed conflict when a newer generation holds the shared head; the #753 activation path hits exactly that when its vectors are bound to a superseded source generation.

[ScriptedAlchemy]

Residual migration cleanup is now reviewed and published on codex/integrate-sept4: 2d3e074 releases legacy replay-only staging rows only from a unique durable retired tombstone, and 9382187 fail-closes destructive eligibility to the exact code-scope:<64 lowercase hex> / code-graph identity. Pending or active replay cannot authorize deletion. Exact SQL lifecycle and identity receipts are cc-4753 and cc-4757; full retention contract 51 passed / 2 intentional ignores at cc-4764; independent review was clean. Keep #836 open until the remaining shipped legacy compatibility paths are drained and deleted after live-store migration evidence.

[ScriptedAlchemy]

Closed by central PR #707 at efce469: per-shard code-graph namespaces (c88fe1b, 9a805e7) plus the residual migration cleanup (2d3e074 tombstone-gated legacy replay-row release, 9382187 fail-closed destructive eligibility) are central. Draining of any remaining pre-cutover containers on the operator profile is an operational follow-up, not a code gap.