feat(harness): lease a pool sandbox for prompt leaves

[pdettori]

Summary

A kind:"prompt" leaf resolved its own sandbox from the environment — ADR-0028 deferred the lease with "prompt leaves inherit /turn's sandbox routing" — so it never consulted one. Two consequences:

1. SH_REMOTE_SANDBOX / SH_RELAY_ADDR are read only on the lease path, so a remote sandbox was unreachable from a prompt leaf.
2. Worse, on any deployment configured the way deploy/knative/service.yaml is (a KAGENTI_SANDBOX_POOL_SELECTOR, no KAGENTI_SANDBOX_POD), resolveSandboxConfig returned null and the leaf's tool calls ran in the harness container's own filesystem — silently, and indistinguishably from a sandbox that answered. Since that container is node:22-alpine, a prompt reading /etc/os-release would confidently report Alpine having touched no sandbox at all.

The driver is the remote-sandbox demo, which needs a free-form prompt to execute its tool calls on a laptop container reached over the sandbox relay.

Changes

Harness

• runPromptLeaf leases through selectPoolSandbox exactly as the converge and solve paths do — heartbeat while the turn runs, release and close the transport in a finally.
• executeTurn gains an optional pre-leased sandbox. resolveTurnSandbox returns it verbatim when present and otherwise falls back to resolveSandboxConfig, so /turn is unchanged. It returns exactly k8sSandboxExtension's argument and is passed through untransformed, so a leased transport cannot be dropped by a field-by-field rebuild.
• This is a superset, not a swap: with no pool selector configured, selectPoolSandbox performs that same single-pod resolution itself and returns null when nothing is set.

Two contract changes, both recorded in the ADR amendment:

• Saturation propagates as {status:"failed", reason:"saturated"} — the sync /runs path already bounded-waits then 503s on it, and classifyOutcome already keeps it retryable for the async queue. The alternative ADR-0028 rejected ("imports the saturation/503 path") is accepted as a consequence rather than avoided; suppressing it would have taken extra code to be less consistent.
• A throw from the turn returns failed/error instead of escaping as a 500, matching converge and solve.

Demo — driven by a free-form prompt, since the reply names the OS it read rather than handing over a flag to trust:

• lib-relay.sh gains dispatch_prompt and assert_reply_contains/_lacks alongside the verdict pair, which relay-leaf-smoke.sh keeps — its binary CLEAR/FLAGGED is the stronger gate for a live smoke that cannot run in CI. tests/lib-relay-shared.test.sh locks both pairs and records why they diverge.
• demo-remote-worker.sh gains Act 3, which it previously stopped short of while the doc claimed every step was asserted: the planted marker (fail-closed if the pod unexpectedly has the file) and the presence-gone teardown, skipped under --keep since that flag promises the worker stays running.

Testing

• 10 new unit tests, each watched fail first: 4 for resolveTurnSandbox, 6 for the lease (transport handed to the turn, remoteSandbox forwarded, request-scoped pool selector, saturation mapped, lease released on success and on a throw).
• make test — 686 pass, 0 fail (includes the deploy shell tests and Go tests). make typecheck clean. shellcheck -x clean on all three scripts apart from SC2329/SC2015 informational findings that predate this change.
• Live end-to-end on kind (make demo-remote-sandbox DEMO_ARGS=--reuse-cluster): 12 assertions passed, 0 failed.

backend                            | what the model said it read
-----------------------------------+----------------------------
in-cluster pod (sandbox-0)         | The system is running Alpine Linux version 3.20.10.
remote host container              | The OS is Red Hat Enterprise Linux version 9.8 (Plow).

PASS: pool selector '...pool=demo-remote-only' matches 0 Running pods
PASS: marker exists only in sh-demo-remote-worker on this host; sandbox-0 has no /tmp/proof.txt
PASS: C/remote/marker: reply names 'tuscan-lentils-16362-43081'
PASS: presence record for sbx-laptop-demo cleared when the worker's Attach stream closed

Same prompt on both backends. B/remote: reply names 'Red Hat' is the assertion that fails on the old code, where both runs report the harness container's Alpine.

Not in scope

A workload-addressed prompt leaf (workloadId) still ignores the workload's own sandboxSelector, and the API boundary still logs that warning. The envelope's sandboxPoolSelector is honoured now, so only the workload-resolver special case remains — whether a workload's pool should bound its prompt leaves is a separate decision, noted as still deferred in the ADR.