feat(runtime-cf): route exec by the container handle, so a run can hold more than one

[debuggingfuture]

Closes #131.

Problem & Insight

exec ran against a client resolved once at Layer build:

const box = getSandbox(ns, sandboxId);   // once, per Layer
…
acquire: () => Effect.succeed({ id: sandboxId }),

So the container handle that every signature in SandboxService already carries selected nothing, and acquire returned the execution's id whatever it was asked for. The comment justified it as "V0 = one container per execution" — reasoning that is circular: one container per execution, therefore one client suffices, therefore a run cannot have two containers.

What it cost. offload-test.stageConcurrency > 1 (#127) was unusable. Turned on for five stages, all five got the same container and raced to wipe each other's checkout — git clone clears its target directory before cloning — and died CheckoutFailed in under five seconds. The knob shipped, was tried, and was reverted the same hour.

Why 2,200 tests did not catch it. Both doubles contradicted the live layer on precisely this property:

^	Double	What it did	Consequence
1	sandbox-fake	minted fake-container-<n> on every acquire	isolated stages looked isolated; the suite agreed
2	sandbox-cf.test's getSandbox mock	getSandbox: () => currentBox — ignored its id	routing was unobservable, so no test could assert it

A fake that is more capable than the thing it stands for does not merely fail to catch a bug; it certifies its absence.

Take

• boxFor(container) resolves per call. getSandbox is lazy — the container is provisioned on first use — so per-call resolution costs nothing and makes the handle mean what the contract always said. The cache and artifact layers have always routed by container.id; the sandbox layer now agrees with them.
• acquire({ key }) derives a second id through the same normalisation as the execution id, over <executionId>:<key>. That inherits the whole preview-URL budget: DNS-safe, ≤ 40 chars, and digested rather than tail-truncated when it does not fit — load-bearing, since preview-sandbox-id.ts documents what tail-truncation cost when a fan-out collided onto one container.
• destroy({ container }) is new. A keyed container is not covered by the dispatcher's end-of-run teardown, which destroys the execution's own id and cannot know what a run named. offload-test reaps each stage's container as that stage finishes; re-deriving the id via acquire is free and replay-safe, so no handle has to survive a step boundary.
• The substrate facade refuses a key rather than ignoring one. It namespaces one sandbox per consumer execution, so there is no second container to hand back — and quietly returning the first is the exact defect this exists to fix.

Both doubles now model the rule, and two tests pin it: unkeyed acquires return the same container, and exec reaches the handle it was given.

Key actions

• Full suite green — 2247 tests, typecheck, oxlint
• stageConcurrency stays unset on consumers until someone turns it on deliberately; this PR only makes it possible

[flaredispatch-fractalboxdev]

AI code review — 💬 Comment

Risk tier: full · 0 critical · 1 warnings · 0 suggestions

Reviewers: security ⚠️ · performance 1 · code-quality 0 · documentation ⚠️ · release-management ⚠️ · compliance ⚠️ · agents-md ⚠️

1. ⚠️ Warning — Keyed stage containers can leak on failed workspace setup

📍 runs/offload-test.ts:802-805

The keyed container is acquired at the start of the stage, but 'reapStageContainer(stage.label)' is only called on the explicit 'dead', 'unreported', 'red', and 'ok' return paths later in the function. If 'workspace()'/'gitClone'/installation or another earlier stage operation fails, 'runStage' can exit without reaching any cleanup call, leaving the keyed container idle until 'sleepAfter' and incurring the full idle charge. Put acquisition and stage execution in a scoped/finally-style cleanup path so every acquired keyed container is destroyed on failure as well as success.

📋 View full logs & reviewed diff ↗