perf(store-runtime): coordinate graph publication per project

[ScriptedAlchemy]

Problem

CodeGraphShardPublicationLocksV1 is documented as serializing scopes that share one project staging store, but the registry is keyed by code_shard (branch/worktree scope). Different scopes therefore receive independent build locks, and manifest projection can finish before the build permit is claimed. Journal resume also retains the replay-pool lock across full seal verification and publication.

Concurrent cold activations can overlap corpus-sized manifests/staging/sealed copies. Existing source comments record 39.9–45.6 GB RSS for a 12.4 GB store, making lock ownership a product-level memory/lifecycle decision.

Required design

• Key publication coordination by project publication shard.
• Hold one permit from manifest projection through publication, with one documented lock order.
• On resume, release replay-pool lock after stable source proof; scan outside it, reacquire, and revalidate exact identity before mutation.
• Replace permanent historical strong lock cells with lifecycle-bound/weak entries.

Acceptance evidence

• Publish 1/2/4/8 distinct worktree scopes for one project and record simultaneous manifest builds plus peak RSS.
• At most one corpus-sized build per project publication shard.
• Retention/replay cleanup is not blocked by seal hashing/materialization.
• Cancellation, retirement races, journal resume, and rollback remain falsifiable.

[ScriptedAlchemy]

Landed the project-scoped publication coordination slice in PR #707 as 1ee88f4.

Counted evidence:

• 8 worktree scopes for one project -> 1 live project-shard lock cell
• peak overlapping claim_build permits: 1
• replay-pool acquisitions occur during digest scan, proving the pool lock is released before hashing
• publication coordination suite: 5/5 passed; journal/seal suite: 10/10 passed

Keeping this issue open for the remaining acceptance evidence: execute full corpus-sized distinct-generation publishes at 1/2/4/8 scopes and record peak RSS. This slice proves lock identity and permit exclusion with deterministic counters, not the requested corpus/RSS measurement.

[ScriptedAlchemy]

Closing with the corpus measurement the slice left open. Harness: 9de84bc8a (concurrent_worktree_scopes_publish_with_one_corpus_build_and_bounded_rss, #[ignore], one scope count per process via TRACEDECAY_PUBLICATION_SCOPES). It drives N distinct worktree generations of one 600-file / 7,200-function project through the production publish_verified_snapshot path concurrently (barrier-released) and counts overlapping build_published_code_graph_manifest_checked calls under cfg(test), sampling RSS at 25 ms and reading VmHWM.

scopes	distinct generations	peak overlapping manifest builds	RSS before → sampled peak	VmHWM after	wall	per-scope publish (s)
1	1	1	0.27 → 0.90 GB	0.85 GB	16.9 s	16.9
2	2	1	0.39 → 1.64 GB	1.56 GB	38.7 s	19.3, 38.7
4	4	1	0.59 → 3.00 GB	2.89 GB	81.7 s	24.0, 62.7, 43.2, 81.7
8	8	1	1.03 → 5.77 GB	5.60 GB	152.1 s	52.0, 132.7, 17.4, 70.3, 113.5, 96.3, 34.6, 152.1

Acceptance as written is met: at most one corpus-sized build per project publication shard at every N (wall ≈ N × single-scope publish confirms serialization), all N scopes share one Arc lock cell, pool-lock release before digest scan and cancellation/retirement/resume/rollback remain covered by the existing 5 + 10 suites (sealed_publication_tests 5/5 on d03c6e982).

Two observations that are not this issue's scope, recorded for follow-up:

• Peak RSS still grows ≈0.6 GB per scope even though builds never overlap: memory acquired during a scope's publish is retained after its permit is released, so serializing builds bounds concurrent build memory but not the publish-time total. Filed as a separate issue.
• claim_build is try-lock + 250 ms polling, so permit hand-off is not FIFO (N=8: scope 2 published first in 17.4 s, scope 7 last at 152 s). Acceptable for correctness; worth knowing if tail latency becomes a product metric.