Promote latest main to testnet-canary

[branarakic]

Summary

Promote the current main head (22a2225289464e06a20fac274053a3b0a75eda09) into testnet-canary using the normal merge-based canary flow.

This preserves the canary branch history while bringing in all changes currently on main. PR #1539 was reverted by #1637 before this promotion, so oxigraph-worker compatibility remains present in the resulting tree.

Branch state

• source: main at 22a2225289464e06a20fac274053a3b0a75eda09
• target: testnet-canary at 378114f8726ef3fb9b0e2df0bb51f0f615d89676
• no existing open main to testnet-canary promotion PR

Verification

Full promotion CI is expected to run on this PR before merge.

[otReviewAgent]

🔴 Bug: Context-graph registration is skipped for every chain adapter, not just V10

What's wrong
The new code removes the only explicit ContextGraphs registration call and assumes every confirmed publish has already registered the KA. That is true for the described V10 publishDirect path, but the public ChainAdapter contract still includes verify and existing adapters may rely on that fallback.

Example
A ChainAdapter whose publish path returns a confirmed onChainResult but relies on verify({ contextGraphId, batchId, merkleRoot, signerSignatures }) to register the KA to the context graph will now return a confirmed publish and promote data locally, while the on-chain ContextGraphs registration never happens.

Suggested direction
Gate the skip on an explicit V10 capability/registration signal, or keep calling chain.verify for non-V10/custom adapters and continue treating the known V10 Hub-authorized revert as non-applicable.

Confidence note
This assumes adapters that implement ChainAdapter.verify remain supported. The interface and EVM/mock adapters still expose verify, but if this release is intentionally V10-only then the compatibility concern should be confirmed by maintainers.

For Agents
In packages/publisher/src/dkg-publisher.ts, keep the V10 fast path only when the adapter/result proves publishDirect already registered the KA. Preserve the old chain.verify fallback for adapters that still need explicit ContextGraphs registration, and add a test with a fake adapter whose verify call is required.

[otReviewAgent]

🔴 Bug: The outbox store interface now requires a new method, breaking existing custom stores

What's wrong
The comment says due(now) remains the required public store contract for compatibility, but hasPendingFor was added as another required method. Existing/custom ProtocolOutboxStore implementations will no longer satisfy the exported interface and can also fail at runtime if consumed from JavaScript.

Example
An out-of-tree store built against the previous ProtocolOutboxStore contract implements enqueue, markDelivered, hasEntry, due, list, and getEntry, but not hasPendingFor. After a send/retry drains the last row, Messenger.clearDhtWalkRateLimitIfDrained calls ProtocolOutbox.hasPendingFor, which calls undefined and crashes at runtime for JavaScript consumers, or fails TypeScript builds for TS consumers.

Suggested direction
Keep the public store contract backward-compatible by making hasPendingFor optional and falling back to list().some(entry => entry.peer === peer), or provide a legacy pendingFor fallback during a deprecation window.

For Agents
In packages/core/src/messenger-types.ts and packages/core/src/protocol-outbox.ts, make hasPendingFor optional or derive it from the required list() method when absent. Add a compatibility test using a legacy due/list-only store to prove Messenger/ProtocolOutbox still work.

[otReviewAgent]

🟡 Issue: Stop growing the daemon request boundary with optional positional state

What's wrong
This makes an already fragile API boundary more brittle. handleRequest is not really a function with 30 independent arguments; it is a request-context factory. Adding another optional tail parameter normalizes positional plumbing and makes future changes harder to review because the important state is hidden in a long call list.

Example
The lifecycle call now passes publisherAvailability after two optional emit callbacks; the callee then stores it as ctx.publisherAvailability. The next daemon-scoped dependency will repeat the same widening pattern.

Suggested direction
Introduce a named dependency object, ideally assembled once in lifecycle and reused per request, so publisher availability is a named field instead of the latest optional positional argument. This also gives future route-wide state a canonical home.

For Agents
Refactor packages/cli/src/daemon/handle-request.ts and the single call in packages/cli/src/daemon/lifecycle.ts to pass a named DaemonRequestDeps/context-builder object. Preserve the route behavior and prove the async publisher unavailable responses still include reason/retryable/operatorActionRequired.

[otReviewAgent]

🟡 Issue: Extract the VM dedup SPARQL rewrite out of the monolithic query engine

What's wrong
The change adds a substantial new mini rewrite engine directly to an already oversized query engine. The raw string slicing, sentinel variables, fallback ordering, and shape scanner are all tightly coupled in one place, which raises the cost of safely changing VM query routing later.

Example
Adding another VM graph source or changing graph-wrapping semantics now requires reading wrapVerifiableMemoryGraphSet, wrapWithProjectedGraphSubselect, wrapWithDeduplicatedGraphValues, sentinel collision handling, and isDedupSafeBasicGraphPattern in one large file.

Suggested direction
Keep the behavior, but isolate this as a dedicated rewrite abstraction with a narrow API. The query engine should route to a named VM graph-rewrite policy, not own the raw SPARQL anti-join construction and safety scanner inline.

Confidence note
This is a structural maintainability concern; the current tests may cover behavior, but the implementation still concentrates too much SPARQL-rewrite machinery in the main query engine file.

For Agents
Move the VM graph-set rewrite policy and helper/sentinel machinery from packages/query/src/dkg-query-engine.ts into a focused module, e.g. verifiable-memory-graph-rewrite.ts. Keep the same fallback order and existing read-both dedup tests, with DKGQueryEngine only invoking the named rewrite function.

[otReviewAgent]

🟡 Issue: Avoid a control-flow error subclass for throttle retry state

What's wrong
This adds an internal error class and couples retry orchestration to runtime error identity. The public read path now has two concepts for endpoint exhaustion: the transport error callers care about and a private subclass used to decide whether to retry. That indirection is avoidable and makes the boundary harder to reason about.

Example
An all-throttled pass throws ProviderSetExhaustedError; the retry wrapper catches it for control flow, and exhausted callers receive a subclassed transport error carrying an internal retry classification.

Suggested direction
Model full-pool exhaustion as a typed internal pass result rather than a thrown subclass. That keeps retry policy explicit in read() and avoids making the public transport error hierarchy double as private control-flow state.

For Agents
In packages/chain/src/rpc-failover-client.ts, split provider-pass execution from public error throwing. Have the pass return a typed exhaustion result carrying { error, allThrottled }, let read() own the retry loop, and throw the existing public ChainRpcTransportError after retries are done. Preserve current tests for all-429 retry, mixed exhaustion, and single-provider messages.

[otReviewAgent]

🟡 Issue: Finalized KA namespace guard lacks a regression test

What's wrong
This guard protects the new named-lifecycle shared-memory scope from using a KA id in another author namespace. The current tests only prove matching author ids are threaded; they would still pass if the mismatch rejection were removed or inverted, leaving a data-isolation regression unverified.

Example
A regression test could persist a finalized seal with authorAddress = AGENT_B and reservedKaId = (BigInt(DEFAULT_AGENT) << 96n) | 1n, then assert publishFromFinalizedAssertion(CG, NAME, { agentAddress: AGENT_B }) rejects with /not in author/ and does not call _loadSelectedSWMQuads or publishFromSharedMemory.

Suggested direction
Add a negative finalized-assertion test for a reservedKaId whose high 160 bits belong to a different author, and assert no publish side effects occur.

Confidence note
The helper is private, so this is based on reachable behavior through publishFromFinalizedAssertion tests rather than direct helper tests.

For Agents
Add coverage in packages/agent/test/publish-finalized-agent-lane.test.ts for sharedMemoryScopeForFinalizedLifecycle behavior through publishFromFinalizedAssertion: mismatched nonzero packed author must reject before loading/publishing; optionally also cover legacy low-96-bit reservedKaId binding to the seal author.

[otReviewAgent]

🟡 Issue: EPCIS publisher-readiness diagnostics are not asserted

What's wrong
The route now exposes user-facing readiness diagnostics, but its test only checks the coarse error name. That gives false confidence for clients/operators relying on the new reason and retryability fields.

Example
If the EPCIS unavailable branch returned { error: 'PublisherUnavailable' } without reason/retryable/operatorActionRequired, or returned retryable: true for no_publisher_wallets, the current EPCIS readiness test would still pass.

Suggested direction
Pin the new EPCIS 503 body fields in route tests, mirroring the knowledge-assets publish-async readiness assertions.

For Agents
Extend packages/cli/test/epcis-route-readiness.test.ts to assert the new response fields for at least publisher_startup_failed/runtime-null, no_publisher_wallets/empty runtime, and publisher_starting via ctx.publisherAvailability. Preserve the existing PublisherDisabled mapping separately.