Promote latest main to testnet-canary

[branarakic]

Summary

Promote the current main head (6613cd4031cc661156e36541381a623f124f9473) into testnet-canary through the normal protected-branch flow.

The final release blockers are now merged and included:

• fix(storage): escape control characters in RDF bindings #1662 — canonical RDF literal codec and storage adapter control-character safety
• fix(build): bound runtime updater UI memory #1663 — bounded runtime updater build and Node UI memory footprint

This promotion also includes every other change merged to main since the previous canary promotion.

Branch state

• Source: main at 6613cd4031cc661156e36541381a623f124f9473
• Target before promotion: testnet-canary at ee1bb05d872907fbf5667df816a16bd39559d025
• GitHub reports the branches conflict-free and mergeable.

Release gate

CI must finish successfully and protected-branch review requirements must be satisfied before a normal merge. After merging, verify that the resulting testnet-canary tree exactly matches main, then confirm all four testnet beacons have adopted the resulting canary revision before running the certification burst.

[otReviewAgent]

🟡 Issue: Random Sampling eligibility is split across lifecycle, bind, and string-matched adapter errors

What's wrong
This adds another state machine to an already broad lifecycle method while the bind layer still owns similar gates. The new lifecycle fields are effectively a shadow status object for the handle. That makes the design harder to reason about and creates drift risk between status reporting, retry scheduling, and actual prover construction.

Example
A future random-sampling eligibility state now has to be threaded through at least two places: lifecycle-owned fields like randomSamplingDisabledReason/randomSamplingIdentityId, and bind-owned noop handle status. Missing one leaves status/logging/retry behavior inconsistent even if the prover behavior still works.

Suggested direction
Move role, identity, readiness, sharding membership, disabled reason, and retryability into a dedicated eligibility helper or bind result. The chain adapter should expose typed unavailable/not-deployed outcomes instead of requiring lifecycle to parse EVM error text.

For Agents
Look at tryStartRandomSamplingProver and random-sampling-bind. Preserve current reasons and retry/disabled outcomes, but introduce one eligibility/result model owned by the random-sampling bind/eligibility module. Lifecycle should call it and only schedule retry/start from the returned result. Prove parity with the existing random-sampling lifecycle tests.

[otReviewAgent]

🟡 Issue: Collapse the two publisher-pricing state machines into one policy-driven flow

What's wrong
The strict and legacy planning paths are implemented as parallel state machines rather than one shared model with different policies. This is exactly the kind of duplicated branching that becomes permanent debt because the two functions must evolve together but nothing enforces that they stay aligned.

Example
If another diagnostic or eligibility condition is added, it has to be added to both resolvers and kept behaviorally aligned. The current implementation already repeats the account lookup, lock lookup, coverage check, quote clamp, and direct fallback branches in two near-identical flows.

Suggested direction
Use a single resolver that performs PCA discovery once and delegates only the strict-vs-legacy policy differences to small strategy functions or options. That would delete duplicated branches while keeping behavior explicit.

For Agents
Refactor publisher-plan.ts around one candidate-pricing engine with an explicit policy object for strict vs legacy behavior: quote required/optional, coverage required/legacy-unchecked, quote failure propagation/fallback. Preserve the public result shapes or adapt callers with a thin formatter, then keep the existing publisher-plan unit tests as parity coverage.

[otReviewAgent]

🟡 Issue: Do not publish low-level publisher-planning internals from the chain package root

What's wrong
The PR adds implementation-specific planning helpers and diagnostic shapes to the public chain package surface. That leaks feature internals across package boundaries and makes future simplification harder because internal policy choices become importable contracts.

Example
A downstream consumer can now import resolveLegacyPublisherCandidatePricing and depend on pricingMode, quoteSource, or legacy-unchecked diagnostics even though those are implementation details of publisher planning rather than stable chain capabilities.

Suggested direction
Narrow the public export surface. If publisher needs legacy fallback logic, own that compatibility helper in the publisher package or expose a deliberately named internal entrypoint instead of the main package index.

Confidence note
This assumes the package root exports are treated as public API, which is the normal expectation for this workspace package.

For Agents
Keep ChainAdapter.resolvePublisherPublishPlan as the cross-package boundary. Move legacy fallback pricing into the publisher package or a private/internal import path, and keep EVM strict pricing package-private to the chain adapter. Only export types that are intended as stable external contracts.