feat: manage hosted sandboxes across local and remote nodes

[SaladDay]

Hosted Sessions can now use local or remote sandbox nodes. Core chooses an eligible node automatically unless creation names one; placement stays fixed across retries, disconnects, restarts and resume. The Hosted Sandbox Manager shows node health, capacity, allocations and Session placement, with enrollment and guarded removal.

Each deployment selects one provider, Docker or microsandbox, behind the common sandbox API. Nodes reconnect without replacing retained resources or replaying uncertain operations. Independent node lifecycle workers prevent one blocked provider from stalling another. Provider switching requires clean maintenance, and legacy adoption requires positive ownership evidence for every retained resource.

The default installer still creates no execution node. Opt-in local providers use private persistent node state outside read-only configuration. Administrator, project, enrollment and node credentials remain separate; the production console forwards explicit administrator credentials only on management routes.

Validation:

• Targeted database, lifecycle, transport and configuration race tests; generated contracts; installer/manifest tests; console authorization/concurrency tests. The node-isolation regression passed five repeated race runs after correcting its test-only idle window; production scheduling and assertion deadlines are unchanged.
• Two KVM hosts: a blocked node stayed owned while another completed two real model Turns, suspension with RAM release, Core restart, exact-snapshot resume, retained files/configuration/history, idempotency and deletion. A full-capacity explicit request refused without fallback or an extra Session.
• Real Docker startup using installer-generated mounts preserved node identity across restart and enforced project/admin separation. Production-console HTTP checks against real Core passed. Test resources and credentials were cleaned.
• Two additional real model Turns on f71dbfa verified the database-clock correction: terminal commit to suspension admission measured 21.10 and 21.64 seconds for a 20-second policy. Both cycles released VM RAM; Core restart resumed the exact snapshot with retained state and no replay. This timing delta passed focused independent review.
• Candidate aa80183 also fixes database presence cancellation ordering. The original failing close regression passed 100 race repetitions; deterministic Store tests cover cancellation before commit, cleanup waiting for commit, newer connection/epoch protection and unrelated-node responsiveness. Negative controls failed on the former implementation. Focused independent review and a two-node production transport smoke passed: original identities reconnected, Core restart advanced the owner epoch, and stale cleanup preserved current connections.
• Candidate 55bced1 integrates main e16c421 and routes Runtime observations through immutable node placement without waking compute or changing idle activity. The unlanded node migration is 000057 after main's 000056 history migration. Generated contracts, handler/server/node/observation checks, Web typecheck and 1,025 Web/client tests passed. Focused merge review and the final real remote-metrics/history smoke passed, with all temporary resources cleaned. API/database/official-client/container CI and native build passed.
• The full make check run reached browser acceptance: 103/104 passed; the remaining failure expected obsolete empty-stream wording after main changed the client error. Final e599a6c changes only that test expectation. Both affected retry cases passed locally in Playwright, including the original-key/non-streaming recovery and exactly-one-Turn assertions. Fresh CI is not awaited; a complete green final make check is not claimed.
• Standalone archive and distribution document staging/archive checks passed.

No Core HA, cross-node restore, provider migration, node drain or cross-Turn Agent process residency is added. Volume-only legacy remnants and incomplete consumed-restore transitions must be resolved on the original backend before upgrade. Live checks cover two nodes, not a 32+ VM load test or full release-bundle qualification; production-console checks use fixture HTML, with browser acceptance covered separately by the repository fixtures.