fix(server): never wedge a thread in stopping when sandbox teardown fails

[awtprod]

A thread whose sandbox teardown hits any snag gets stuck in stopping forever — every new turn is rejected and the thread is permanently unusable. Three release-blocking lifecycle bugs, all found on this branch and each sufficient to strand a user's thread on its own:

1. stop() destroyed its own workspace container. The sibling-cleanup phase listed the thread's containers by ID but excluded the workspace container by comparing those IDs against its name — never equal — so every orderly stop force-removed its own workspace container as a "sibling". The later cleanup rm by name then failed, stop() threw, and the stop never completed. Fixed by listing {{.ID}}\t{{.Names}} and excluding by name (the egress sidecar, also removed by name later, is excluded the same way). The per-candidate label verification is unchanged.

2. The lifecycle reactor early-returned without completing the stop. The decider accepts sandbox.stop from every non-terminal lifecycle — including unprovisioned and failed, which never recorded a runtime — and moves the thread to stopping unconditionally, but the reactor returned early for those threads without dispatching sandbox.stop.complete. Now it always completes: nothing to tear down still dispatches stop.complete, and a teardown failure flows to the existing sandbox.operation.fail path (stage teardown, carrying the runtime's real error), which the decider resolves from stopping to failed — re-provisionable, not wedged. A decider test pins that transition. SandboxSettleCleanupReactor's narrow guard is deliberately left as-is; its comment now records that the trap it worked around is gone.

3. Stale execution-target cache served dead containers. ProviderCommandReactor's per-thread target cache was never invalidated when a sandbox stopped, expired, or failed, so a cache hit could hand the provider a destroyed container's name. Cache hits are now validated under the provision lock against the current sandbox projection (lifecycle ready, same sandboxId/runtimeRef); anything else evicts and re-provisions. The maps are one tiny entry per sandbox thread, documented as such — staleness, not growth, was the defect.

Every fix ships with regression tests that fail on the reverted code (verified by reverting each fix momentarily): the bug-1 tests stub ps with a non-empty listing — every prior stop test stubbed it empty, which is why this survived — the bug-2 tests assert a completion or an operation.fail is dispatched in both no-container and teardown-failure paths, and the bug-3 test provisions, stops through the real command path, and asserts the next turn re-provisions rather than serving the dead generation's name.

Stacked on #47 (fix/sandbox-graceful-fallback); retarget to main after that merges.

Verification: vp check exits 0, vpr typecheck exits 0, full server suite CI=true pnpm -C apps/server test green (3263 passed, 19 skipped, 329 files).

Claude Fable 5 via Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.6 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.7 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	54.2 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	17	—	21	✅
Claude	Total thread wire	—	13.7 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.0 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.7 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.0 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	17	—	21	✅

Baseline: unavailable · PR result: 0888a72 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 107.8 KiB
• Claude decoded thread snapshot: 108.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.