fix(gateway): close chat-start + sandbox lifecycle races

[DIodide]

Systematic bug hunt over chat start and the sandbox edge cases: three parallel finder agents (concurrency, sandbox-vanished/error-state, workspace-unify) + a 17-agent adversarial verification workflow over the fixes themselves. Every CONFIRMED finding is fixed, each with the concrete interleaving that triggered it and a regression test where practical.

The bugs (4 commits)

Chat-start races (session_manager.py):

1. create() TOCTOU — the one-session-per-conversation dedup and the insert straddled the multi-second credential bake, so two tabs / a reload double-provisioned one conversation (two shims in one attached box; the second launch rotated the first's preview token). Now re-checks + reserves the slot synchronously before baking; a prepare() failure drops the reservation, sets the user-facing session.error, and unblocks awaiters.
2. close() during provisioning orphaned the sandbox — _teardown short-circuits on runtime=None while the background provision kept building a box invisible to the reaper (leaking against the per-user cap). _provision now reclaims it, and create()/_provision_once skip dead reservations entirely.
3. Concurrent revive double-provisioned — two turns on a stale session both failed healthz before either flipped to "reviving"; both re-launched the sandbox, the second orphaning the first's shim. Revive now serializes under session.lock with a health re-check.
4. set_config_option / switch_harness unguarded — a concurrent "new chat" steal (_claim_parked) or rewind (reset_conversation) could tear the runtime out from under them mid-call. Both now hold turn_guard, like prompt.

Sandbox lifecycle:

5. Transient recover() failures tombstoned as "gone" (daytona_service.py) — a 429/5xx/timeout during recovery made revive delete a still-alive owned box and replace it empty (data loss). Now disambiguated: after a transient-looking failure the state is re-fetched — landed-back-in-error → the "gone" heal (retrying can never fix it); a genuine blip → re-raise for backoff.
6. Fresh-workspace race built two unified boxes — two chats starting concurrently in a workspace with no box yet each built one; the loser lost the Convex link race and ran its whole chat in a throwaway box whose files were silently discarded. First-box creation now serializes on a per-workspace lock; the loser re-resolves and attaches to the winner's box. The vanished-box heal re-enters the locked flow too (and the lock is released before a re-resolved attach, so the heal can never self-deadlock).
7. Stale/foreign workspace link never unlinked — createInternal's lost-race guard then declined every fresh box, churning a new box per session forever. Now unlinks via a new workspaces:unlinkSandboxInternal scoped to the one workspace link and userId-gated (workspace_id is client-supplied; the broad removeByDaytonaId stays reserved for provably-gone boxes).
8. Provision wall-clock (180s) smaller than the budgets it wraps — archived restore alone is 180s, first-attach bootstrap 300s, so legitimate cold starts reliably timed out. Now 360s.
9. Teardown/park pointer hazard — _teardown now detaches session.runtime synchronously before any await, so the closed-mid-provision reclaim can never destroy a runtime that was just parked (and possibly adopted by a new session).

Verification

• New regression tests: concurrent-create dedup + failed-reservation cleanup, concurrent first-provision serialization, transient-vs-deterministic recover() split, scoped-unlink blast radius (Convex, incl. cross-user no-op).
• fastapi 375 passed · convex 221 passed, tsc + biome + ruff clean on touched files.
• Adversarial workflow findings on the fix commit itself: all 6 addressed in the follow-up commits (f408920, b23db92, a8710c8).

Known-deferred (LOW / not confirmed)

• queue_prompt racing the done-yield suspension (queued message lost in a sub-tick window).
• _take_over_attached tearing down a mid-turn holder (partially by design — attach takeover is last-writer-wins).
• The advisory "turn already in progress" check (double-submit becomes two sequential turns).
• Transient retries in tooling-route _ensure_running; 30s _running_cache staleness window.