test(rfc64): certify finalized private SWM retirement

[branarakic]

User impact

A node recovering a selected private context graph can now be certified against the real RFC-64 lifecycle: it authenticates and activates every catalog SWM payload, reconstructs the exact finalized VM state, durably commits and post-reads the applied catalog head, and only then retires the duplicate SWM twin.

This PR is the release gate for the runtime ordering implemented by #2412. It prevents a canary from passing merely because the final store happens to look correct after an unsafe early retirement.

Before

sequenceDiagram
    participant Receiver
    participant Catalog as RFC-64 catalog
    participant SWM as SWM store
    participant VM as Finalized VM
    participant Gate as Release gate

    Receiver->>Catalog: Fetch private catalog
    Receiver->>SWM: Activate authenticated payloads
    Receiver->>VM: Materialize finalized projections
    Receiver->>SWM: Retire duplicate twins
    Gate->>SWM: Read final empty state
    Gate->>VM: Read final VM state
    Note over Gate: Safe temporal order is inferred

Loading

After

sequenceDiagram
    participant Receiver
    participant Catalog as RFC-64 catalog
    participant VM as Finalized VM
    participant Head as Applied-head store
    participant SWM as SWM store
    participant Gate as Release gate

    Receiver->>Catalog: Fetch and verify private catalog
    Receiver->>VM: Materialize and post-read exact finalized rows
    Receiver->>VM: Commit VM transaction
    Receiver->>Head: Commit and post-read exact catalog head
    Head-->>Receiver: Receiver-owned committed-head token
    Receiver->>SWM: Reconcile duplicate twin after durable token
    Receiver-->>Gate: Typed per-KA lifecycle receipts
    Gate->>VM: Independently read exact projection bytes
    Gate->>Gate: Recompute VM digest and require cold materialization
    Gate->>SWM: Verify exact retired state

Loading

What the gate proves

• All 32 private SWM assets were authenticated and activated before retirement.
• All 32 finalized VM projections were materialized on the cold receiver with exact bytes, metadata, and chain ordinals.
• Every lifecycle receipt is bound to the catalog head, inventory digest, UAL, VM graph, VM post-read digest, and receiver-owned durable committed-head token.
• The process boundary reads receipts from the existing synchronization evidence, uses the canonical production receipt type, preserves every modeled field including subGraphName, rejects malformed, duplicate, and out-of-order receipts, and emits deterministic canonical UAL order.
• A receipt with existing status or the wrong VM post-read digest cannot pass.
• Provider failover preserves the same completeness and performs a verified provider switch.

Evidence

Validated at head f36a3f05d on runtime base #2412 head e0c502980.

• Focused receipt decoder/verifier: 4/4 passed.
• Private CP2: SWM activated 32/32, SWM retired 32/32, VM 32/32.
• CP2 artifact digest: 0xd779811873c1e2333aa53ff775c0eb98f8e788f1d37a36c06ae3ea97155832a6.
• Four-process private provider failover: SWM 32/32, VM 32/32, provider switches 1.
• CP3 artifact digest: 0x4df079ac66073d779672317f74c06dd23e69c7916d15b78595c7300762258ccc.
• CP2 and CP3 TypeScript gates passed.
• Agent build, type tests, package-root export boundary, root lint, and diff checks passed.

Scope

This PR changes the CP2 certification runner and adds its typed wire decoder/verifier tests. It also extracts the committed-head token and lifecycle-receipt interfaces into pure internal agent contract modules so the harness consumes the exact production types without importing the full runtime. Both extracted modules remain explicitly blocked from the public package root.

[branarakic]

Revalidated the certification gate after restacking onto lifecycle head e232508ff (this PR head 0e75ae455):

• private mixed lifecycle: SWM activated 32/32, retired 32/32, finalized VM 32/32
• private provider failover: SWM 32/32, VM 32/32, provider switches 1
• exact artifacts: 0x7134f87180fcb927c4736f4aa6b582c27fbd50663957ce7fab52f9f275bd4e4e and 0x267782bec64bfcc51b49d3a92a6d7ddbb32476bb4afdf167be969d334cf108a9

This confirms the lifecycle fixes did not regress private recovery or failover.

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: Selected model is at capacity. Please try a different model.

[otReviewAgent]

🟡 Issue: The repair store is a pass-through facade while the monolith keeps growing

What's wrong
The new store abstraction does not own storage behavior; it merely renames synchronous inventory methods and presents them as promises. Persistence then wraps it again, while all substantive queue logic is inserted into the 3k-line CandidateInventoryV1 class. This adds indirection without modularity and materially worsens an already oversized core file.

Example
A put currently travels through the owned-persistence wrapper, the repair-store wrapper, the inventory foundation forwarding method, and finally CandidateInventoryV1. The nominal store module owns none of the SQLite implementation that would justify these layers.

Suggested direction
Make this module the real repair-queue repository, or delete the store facade and provide one canonical non-owning operations view directly from inventory persistence. Keep one clear boundary rather than four forwarding layers.

For Agents
Move the repair queue's SQLite repository implementation out of inventory-v1/candidate.ts into a focused persistence module, or expose the candidate implementation through one canonical lifecycle-fenced operations view like the existing SWM inventory capability. Remove the duplicate async renaming facade and forwarding layers. Preserve canonical serialization, digest binding, transaction recovery, and close fencing; keep the repair-store and inventory lifecycle tests passing through the simplified boundary.

[branarakic]

Superseded by merged integration PR #2432. The current head of this stacked PR is contained in testnet-canary.