Promote testnet-canary to main (10.0.9 line + fifa-class meta ceiling fix)

[branarakic]

Promotes the full testnet-canary line to main — 92 commits, zero conflicts (main was fully back-merged into canary via #1884/#1886 first, per release-cut convention).

What this brings to main

• 10.0.9 line (fix(sync): batched exact VM reconciliation (#1871) + lazy on-chain probe (#1852) #1876): exact-batch VM reconciliation (feat(agent): batch exact missing VM asset reconciliation #1871 head incl. the three race/boundary fixes), lazy on-chain public probe (fix(swm): evaluate on-chain public probe lazily — restores receive-path latency #1852), public-CG SWM/VM sync fixes (Codex/v10.0.9 testnet canary #1845 line: Fix Markdown KA visibility after SWM sharing #1779/fix(publish): let a curator VM-publish a member-shared rootless KA (#1778) #1780/fix(swm): materialize verified public snapshots on catch-up #1842/fix(swm): accept plaintext SWM on public-on-chain agent-gated context graphs #1843/test(devnet): add public Context Graph SWM+VM sync proof harness #1844)
• Fifa-class fix (fix(sync): remove 64k _meta ceiling + materialize catch-up snapshots (fifa-class CGs) #1880, approved by @branarakic): removes the 64,000-row _meta snapshot ceiling — bounded session-plan lane with per-subject count + sha-256 digest page verification; hold-out node reconstructs the full corpus (100/100 quads)
• feat(publisher): append-only admission & transaction journal (#1829) #1875: append-only admission & transaction journal (+ fix(agent): verify durable CG identity on chain #1885 cg-hash fallback, Fix public context graph metadata projection #1866 public meta projection, Fix public Context Graph review follow-ups #1853/Fix public Context Graph subscription catch-up #1848 public-CG hardening)
• Devnet proof harness (devnet/public-cg-sync-proof/) used to gate all of the above

Verification

• The exact union tree was gated: full monorepo build TS:0, publisher unit suite 472/472, cli unit suite green (the feat(publisher): exact intent recovery lookup for lost async-publish admissions (#1828) #1849/fix(publisher): fsync the broadcast record before send to prevent crash-recovery double-submit #1851 vs feat(publisher): append-only admission & transaction journal (#1829) #1875 reconciliation was hand-verified hunk-by-hunk in Merge main into testnet-canary (#1849 intent-key lookup + #1851 broadcast durability) #1884 — canary is a strict superset)
• fix(sync): remove 64k _meta ceiling + materialize catch-up snapshots (fifa-class CGs) #1880's own gate: devnet proof 32/34 (only the two known watermark-counter checks fail — pre-existing, documented, not a health signal), hold-out 100/100

🤖 Generated with Claude Code

[otReviewAgent]

🔴 Bug: Intent recovery loses curator-published member jobs

What's wrong
The change correctly separates caller from author for publishing, but the recovery API still assumes the authenticated caller is the lifecycle agentAddress when the client omits that field. That assumption is false for the new curator-publishes-member flow, so the durable admission recovery and facts-based journal can miss exactly the jobs this PR now supports.

Example
Curator 0xCurator publishes member 0xMember's shared KA through publish-async. The admitted job is keyed by (contextGraphId, name, subGraphName, 0xMember). If the 202 response is lost, the curator retries recovery with GET /api/publisher/job-by-intent?contextGraphId=cg&name=asset using their token; the route fills agentAddress=0xCurator, derives a different lifecycle key, and returns none even though the job exists.

Suggested direction
Keep the new resolved-author publish behavior, but make retained-facts recovery derive the same author before building the lifecycle key, or return an explicit recovery token/facts shape that includes the resolved author in every admission response and caller flow.

For Agents
Update the publisher intent/journal lookup path to mirror publish author resolution for omitted agentAddress: preserve explicit agentAddress as an author selector, but when omitted resolve the finalized assertion author from contextGraphId, name, optional subGraphName, and the caller as a hint. Add a regression where a curator enqueues async VM publish for a member-shared KA, then /api/publisher/job-by-intent and /api/publisher/journal without agentAddress find the member-keyed job/lineage.

[otReviewAgent]

🔴 Bug: Metadata-pending recovery is not tested through the production batch path

What's wrong
The change is meant to fix the reconcile state called out in the verification notes, but the tests do not exercise the path production now uses for that condition. This leaves the exact watermark-stuck regression underverified.

Example
A regression that keeps inline fetching for verified-vm-metadata-pending but returns plain { status: 'pending' } when deferActiveFetch: true would leave the production watermark stuck, while the current metadata-pending and batch tests still pass.

Suggested direction
Add a regression test for verified-vm-metadata-pending in the deferred/batched reconciler path, not only the legacy inline fetch path.

For Agents
In packages/agent/test/core-fills-gap.test.ts, add a runVmReconcileForCg or createVmReconcileDeps test that uses the real reconcileChainOrdinal with handleChainReconciledKC returning verified-vm-metadata-pending, asserts recoverVmReconcileBatch receives a target with that reason, and proves the recovered outcome advances the watermark.

[otReviewAgent]

🟡 Issue: Model snapshot materialization as one dependency, not two loose optionals

What's wrong
The new comment says materialization needs “ONE cohesive dependency”, but the interface still exposes the materializer and snapshot store independently. That keeps the half-configured mode alive at the type boundary and forces readers to discover the real invariant inside the control flow.

Example
A test or alternate runtime can pass publicSnapshotStore but forget snapshotMaterializer; TypeScript accepts it, runSharedMemorySync still runs, and public snapshot materialization is quietly skipped.

Suggested direction
Make the type boundary express the invariant the comment already describes: materialization is either fully configured or absent. Avoid a half-configured state that compiles and degrades silently.

For Agents
In packages/agent/src/sync/requester/shared-memory-sync.ts, replace the two independent optionals with one cohesive option, for example snapshotRecovery?: { materializer: SharedMemorySnapshotMaterializer; publicSnapshotStore: WorkspacePublicSnapshotStore }, and update production/tests to either supply both or omit the whole feature.

[otReviewAgent]

🟡 Issue: Extract the new TTL SWM meta planner out of the monolithic graph planner

What's wrong
This PR drops almost a thousand net lines into a file that was already nearly 3k lines. The new code is not a small extension; it is a distinct pagination subsystem with its own state model and budget semantics. Keeping it embedded makes the responder planner harder to scan and makes future changes to unrelated lanes riskier.

Example
To reason about TTL SWM meta paging now, a reader has to jump between the new plan types near the top of the file, the shared memo helper, readSwmMetaPage, and several hundred lines of fresh-meta implementation near line 2454.

Suggested direction
Use the self-contained nature of this change as the extraction boundary. Moving the new planner into its own module would delete a large amount of local coupling from graph-plan.ts without changing behavior.

For Agents
Extract the TTL-filtered SWM meta plan into a focused responder module, such as fresh-swm-meta-plan.ts, with a small exported readFreshSwmMetaPage/memo factory. Keep graph-plan.ts as orchestration over graph-plan lanes, and preserve the existing query and budget behavior with the current tests.

[otReviewAgent]

🟡 Issue: Split the TTL SWM meta planner out of graph-plan.ts

What's wrong
The PR adds almost a thousand net lines of a distinct subsystem into an already monolithic responder file. The implementation may be carefully reasoned, but the structure makes unrelated responder concerns harder to scan and makes future changes riskier because every paging mode now shares one oversized module.

Example
To understand the new readSwmMetaPage path, a reader has to chase FreshSwmMetaPlan, freshSwmMetaSessionDigests, createSessionPlanGetter, readFreshSwmMetaSubjects, buildFreshSwmMetaPlan, readFreshSwmMetaRowsPageFromPlan, and readBoundedFreshSwmMetaSnapshot inside the same 3.7k-line module.

Suggested direction
Move this feature’s planner and paging machinery behind a dedicated module boundary instead of growing the already-large responder graph planner.

For Agents
Extract the new TTL SWM meta planner into a focused responder module, for example sync/responder/swm-meta-plan.ts, including the plan types, digest sidecar, discovery/count/window readers, bounded snapshot fallback, and memo factory. Leave graph-plan.ts as a thin dispatcher/export surface and preserve the existing tests against the extracted functions.

[otReviewAgent]

🟡 Issue: Stop extending the sync request path with more positional optionals

What's wrong
The exact-asset feature is threaded through the sync stack by appending another optional positional argument to an already-long function type. This makes the sync boundary brittle: the identity fields that define a page request are spread across ordered parameters instead of one explicit model.

Example
A call that needs assetUals must pass through snapshotRef, sinceBatchId, syncSessionId, and recovery in the exact order, often as undefined placeholders. That is the same class of positional-control-flag coupling this PR elsewhere works to remove.

Suggested direction
Reframe this boundary around a typed parameter object or a SyncPageRequest model so new selection/session fields are named at every call site and cannot drift by argument order.

Confidence note
The current call sites appear updated, but the concern is maintainability of the widened boundary rather than an observed behavior failure.

For Agents
Introduce a request object for sync page construction, for example buildSyncRequest({ contextGraphId, offset, limit, includeSharedMemory, remotePeerId, phase, snapshotRef, sinceBatchId, syncSessionId, recovery, assetUals }), and thread that object through fetchSyncPages/agent adapters. Keep existing wire encoding unchanged.

[otReviewAgent]

🟡 Issue: Encrypted public-gated SWM acceptance is only verified at the helper level

What's wrong
The production behavior changed from a single “requires encryption” decision to separate “requires” and “supports” decisions. The test suite validates that split in the pure policy helper, but it does not prove the handler actually accepts encrypted payloads in the public+agent-gated skew case.

Example
If this branch were accidentally changed back to if (!requiresEncryptedPayload), the pure helper test would still pass and the plaintext handler test would still pass, but an encrypted Sender-Key write for a public+agent-gated CG with publicAccessPolicyOnChainOracle returning true would be rejected.

Suggested direction
Cover the real handler encrypted/Sender-Key branch for requiresEncryptedPayload=false and supportsEncryptedPayload=true.

Confidence note
I found helper-level assertions for encrypted support and handler-level assertions for plaintext public-gated writes, but not a handler-level encrypted/Sender-Key public-gated apply case in the changed tests.

For Agents
Add a SharedMemoryHandler test in packages/publisher/test/swm-public-gated-plaintext-accept.test.ts that builds a public+agent-gated CG, provides a public-on-chain oracle returning true, sends a decryptable Sender-Key or legacy encrypted payload, and asserts the handler applies it instead of rejecting it as unsupported.

[otReviewAgent]

🔴 Bug: Exact VM recovery can permanently skip peers after the first three

What's wrong
The new batched VM recovery replaces the old rotating catch-up path with a fixed first-three peer slice. Because the ordering is stable and there is no exact-recovery rotation cursor, any peer after that slice is never tried on later sweeps. That leaves chain reconciliation stuck for valid network states where only a later connected peer has the missing KA.

Example
With five admitted connected peers, if peers 1-3 do not have the requested VM snapshot and peer 4 does, each reconcile sweep retries only peers 1-3. The exact fetch returns no materialized asset, the ordinal remains pending, and the watermark never advances even though a connected peer could serve it.

Suggested direction
Preserve bounded work per pass, but make the peer window rotate or otherwise prove that all admitted connected peers are eventually attempted before treating the recovery as unproductive.

For Agents
In recoverVmReconcileBatch, keep the per-pass cap if needed but rotate across the full admitted connected peer set, for example by reusing selectCatchupPeerWindow with a peerRotationKey or by adding an exact-recovery cursor. Add a test where the first three peers return empty and a later peer serves the requested UAL; the reconcile pass should eventually clear the pending ordinal.

[otReviewAgent]

🔴 Bug: Raw-lift journal test exercises a VM-publish job instead

What's wrong
This test gives false confidence for the new journal skip path. It claims to verify raw-lift jobs are not journaled, but it only enqueues a named KA VM publish job and then asserts that job produced one journal row.

Example
If the non-KA guard in appendJournal were removed or broken, this test would still pass because it only observes the one VM-publish admission entry it created itself, not a raw-lift transition.

Suggested direction
Make the test construct and process an actual jobType: 'lift' job so it proves non-named-KA journal writes are skipped.

For Agents
Replace this case with a real legacy raw-lift job, for example using the existing raw-lift test seeder, with journalWrites: true. Drive a transition that calls writeJob, assert it does not throw, and assert no journal entry is written for that raw-lift job.

[otReviewAgent]

🟡 Issue: Journal lookup defaults to the caller even though jobs are keyed by author

What's wrong
The new caller/author split means async publish jobs and journal entries are keyed by the resolved KA author, not necessarily the token holder. The route parser still defaults missing agentAddress to the request caller, so the read APIs miss the exact curator-publishes-member flow this PR adds support for.

Example
A curator 0x11... enqueues async VM publish for a member-authored KA resolved as agentAddress=0x22... and callerAgentAddress=0x11.... Later, the curator calls /api/publisher/journal?contextGraphId=cg&name=asset without agentAddress. The route looks up the lineage under 0x11..., while the journal entry was stored under 0x22..., so it returns an empty result despite the job existing.

Suggested direction
Do not silently use the caller as the lifecycle author for these recovery reads. Resolve the finalized assertion author, query the author lane, or return an ambiguity error that tells clients to provide the author address.

For Agents
Update the /job-by-intent and /journal facts path so omitted agentAddress resolves the same author used at admission, or require the author selector explicitly when it cannot be resolved. Preserve the caller/author split and add a curator-publishes-member async test that queries the journal without agentAddress.

[otReviewAgent]

🟡 Issue: Do not scatter journal kind literals through every state write

What's wrong
Adding the journal by changing the low-level persistence method forces many unrelated branches to know the journal taxonomy. That spreads a cross-cutting concern through the state machine and makes future transitions easy to misclassify or forget.

Example
recordPublishResult advances one job through broadcast, included, and finalized by pairing each mergeJob(...) with a separate writeJob(next, '...') literal. The state transition and its journal classification are now two parallel facts that must remain synchronized by hand.

Suggested direction
Collapse the journaling taxonomy into the publisher state-transition abstraction so callers persist a transition, not a job plus a manually synchronized journal label.

Confidence note
This is a structural maintainability concern, not a claim that the current journal kinds are behaviorally wrong.

For Agents
Centralize journal classification around the state-transition boundary. One direction: introduce a persistTransition helper that derives the default persisted kind from the transition and accepts a small explicit override only for exceptional cases like recovery reset or rollback no-op. Make the no-op sentinel unrepresentable inside buildJournalEntry rather than cast away the type.

[otReviewAgent]

🟡 Issue: Public metadata proof tests are not wired into the unit suite

What's wrong
The PR adds dedicated tests for the new public metadata proof and repair behavior, but the selective unit config does not execute them. This leaves the most direct validation out of the standard unit test lane.

Example
Running the normal agent unit suite via pnpm --filter @origintrail-official/dkg-agent test:unit will not select the new public metadata proof/repair tests, so a regression in the canonical public proof query or creator-owned repair can still pass that lane.

Suggested direction
Include the new public metadata tests in the selective unit config so standard CI validates the new proof and repair paths.

For Agents
Add test/context-graph-public-meta-proof.test.ts, test/context-graph-public-meta-repair.test.ts, and test/context-graph-public-meta-repair-http.test.ts to packages/agent/vitest.unit.config.ts, or move equivalent assertions into included files. Verify with the standard agent test:unit command.

[branarakic]

Adversarially verified each otReviewAgent finding against the promote head (6 independent code-trace passes). Verdicts:

Finding	Verdict	Real severity
🔴 Intent recovery loses curator-published member jobs	CONFIRMED	Real bug, non-blocking — bounded to recovery/journal visibility. Admission keys the lifecycle lane by the resolved MEMBER author (dkg-agent-publish.ts:4201, by design per bc0c4ea), while /job-by-intent + /journal default an omitted agentAddress to the authenticated caller → false none for the curator flow. No double-publish is possible (re-enqueue dedups to the same member-lane jobId) and explicit ?agentAddress=<member> is a full workaround.
🔴 Metadata-pending not tested through batch path	CONFIRMED as test gap only — production path traced correct: dkg-agent-swm-host.ts:3891-3910 emits the recovery target under deferActiveFetch:true and recoverVmReconcileBatch fetches metadata. But no test in the repo calls the real reconcileChainOrdinal with deferActiveFetch:true — all batch tests stub it with reason no-swm.
🟡 Two loose optionals (materializer/store)	PARTIALLY CONFIRMED — type looseness real, but the dangerous half-config is unreachable from the single production call site, the reachable half throws loudly, and the digest-bound guard self-heals. Type-hygiene follow-up.
🟡 Extract TTL planner from graph-plan.ts	CONFIRMED — numbers verified (2906 → 3692 lines; ~700-line self-contained lane). Behavior-preserving extraction is straightforward.
🟡 Positional optionals in sync path	CONFIRMED — worse than stated: assetUals is the 11th positional param, three adjacent same-typed optional strings would transpose silently, and it sits at different positions in four parallel signatures. Same bug class as the fallbackOnPerSnapshotBudget positional bug behind #1847.
🟡 Handler-level encrypted public-gated test missing	CONFIRMED test gap — the supportsEncryptedPayload branches (workspace-handler.ts:1077, :1113) have no handler-level encrypted apply test; the suggested mutation would survive the suite.

Disposition: none of these block the promote — every line is already merged to testnet-canary and running on the testnet fleet; holding this PR protects nothing. All six are queued as follow-up PRs against main after promotion: (1) recovery-route author fallback + resolved author in the 202 response + curator/member recovery test, (2) deferActiveFetch:true regression test, (3) cohesive snapshot-recovery dep, (4) swm-meta-plan.ts extraction, (5) SyncPageRequest object, (6) handler-level encrypted apply test.

🤖 Generated with Claude Code