fix(sandbox): rotate stale runtimes safely

[iamjr15]

Summary

• replace a user's stale Daytona runtime container on the first workspace operation after a snapshot or target promotion
• preserve the canonical persistent-volume subpath, project files, uploaded files, and user-installed skills
• fence concurrent operations and active run leases during replacement, while returning retriable maintenance responses
• clear only ephemeral process reservations and runtime projections after the new container starts
• require canonical ownership, matching snapshot attestation, and the exact workspace mount before automatic deletion; ambiguous contracts still fail closed
• document the production promotion and recovery contract

Why

Promoting the Node 24 snapshot made every existing sandbox permanently return unavailable_maintenance: lookup detected the old snapshot, but no lifecycle path ever replaced it. This change makes immutable snapshot promotion operational without moving or deleting user workspace data.

The replacement decision is intentionally narrow. Snapshot or target drift is recoverable only when the existing resource is unambiguously the user's canonical sandbox on the configured persistent volume. Identity, label, mount, and duplicate-resource ambiguity remain operator-visible failures.

Verification

• pnpm turbo lint typecheck build under Node 24.18.0
• agent-worker lint, typecheck, and Wrangler dry-run build under Node 24.18.0
• dependency-cruiser architecture check for apps/agent-worker
• Knip dead-code check for @cheatcode/agent-worker
• git diff --check
• exactly one SQL migration exists: packages/db/drizzle/0000_current_schema.sql
• production migration dry-run reports that migration applied and verifies the schema contract

Production upload/persistence acceptance QA will run directly through agent-browser after the exact merged revision is deployed.