feat(provider-tangle): consume sidecar capability discovery and interaction ledger (retained-control phase 2)

[drewstone]

Context

agent-sdk#146 phase 1 shipped (agent-provider-tangle@0.7.0): capability claims now derive from a probed SDK surface, and the provider claims retained control only when cancelRun is proven. The ADC server surface it needs also landed on agent-dev-container develop:

• authenticated GET /capabilities (PR #5316) — the deployed run-control facts.
• durable interaction-response ledger (PR #5317) — retry-safe answer/permission/plan with replay and conflict acknowledgements.

Remaining work (phase 2)

1. Consume GET /capabilities instead of inferring from SDK method presence. The provider must call box.capabilities() (or the SDK wrapper) and gate its capability document on the deployed sidecar's reported facts, not the linked SDK class. box.capabilities() returns null on a pre-capability sidecar — treat null as fail-closed (no retained control claim).
2. Implement respondToInteraction over the retained SandboxSession, mapping canonical InteractionResponseCommand (question / permission / plan) to session.answer / respondToPermission / approvePlan / rejectPlan, returning InteractionAcknowledgement (applied / already_resolved_same / already_resolved_different / binding_mismatch). Stop deleting interactions from the capability document; emit an InteractionCapabilities document narrowed by what the session exposes. The server ledger already gives retry-safe semantics.
3. Fresh-process reconstruction proof: today the retained-control tests reconnect in-process. Add a proof that provider.get reconstructs the exact environment and session in a fresh process using only the persisted control reference.

Not in scope (separate issues)

• Workspace branching — no idempotent server surface exists yet.
• Create receipt (new vs idempotent replay) — needs a new agent-interface contract.

Refs #146

[drewstone]

Split: the retained-control half ships, the interaction half is blocked upstream

Shipped / shipping

• @tangle-network/sandbox@0.22.0 is published and exposes box.capabilities() (returns SandboxRuntimeCapabilities | null; null means the deployment predates capability discovery or serves a newer schema).
• The sidecar now advertises interactions.responseDedupe: true (agent-dev-container#5420), pinned to the real ledger by a mutation-proven coupling test.
• Retained control now derives from the deployment's document instead of the linked SDK's method surface — branch feat/154-consume-capability-discovery, in final review.

The interaction half is deliberately NOT shipping, and the reason is worth recording rather than working around.

The Sandbox SDK cannot express two facts this contract needs (filed as agent-dev-container#5421):

1. An answer cannot be aimed at a specific interaction. session.answer() carries no id; the SDK re-lists interactions and posts to the first question it finds. With two questions outstanding, an answer intended for the newer one is delivered to the older one and the caller is told accepted. Adversarial review reproduced exactly this.
2. The server's resolution verdict is discarded. The sidecar returns accepted vs already_resolved_same (and a conflict digest on 409), but the SDK throws the body away — so a provider cannot honestly report that a retry was deduped.

Both workarounds are unacceptable. Guessing delivers a wrong answer to a running agent. Refusing whenever the adapter cannot aim wedges the session — and review found the conservative version worse still: one lost acknowledgement wedges every later question on that session permanently, because the adapter can never learn an ask left the runtime's outstanding set.

So the honest state is: the server side is complete and self-advertising; the client surface is the missing link. The neutral provider keeps interactions unclaimed (fail-closed) until #5421 lands, at which point the wiring is small and the branch feat/154-interaction-responses is the starting point.

This issue stays open for that half.