feat: add optional single-host sandbox suspension

[SaladDay]

Idle hosted Sessions currently keep compute memory allocated. This adds optional microsandbox v0.7.2 suspension: after a terminal Turn and sustained inactivity with no pending work, Core captures and removes compute, then restores the next Turn in the same Session with history, files and configuration preserved. Docker remains available with its existing lifecycle. Native harness behavior is unchanged.

V1 selects exactly one provider and installation per deployment. The private setup configuration rejects provider maps and engine-based placement. A provider change requires persisted maintenance on the old installation, no unreleased instances/snapshots/uncertain operations/pending cleanup or unallocated hosted Sessions, and the incoming configuration still in maintenance. Refusal preserves resource ownership and explains the blocker. Switching does not delete resources or migrate Sessions. A separate restart with maintenance off reopens creation.

Core uses the shared five-operation sandbox API plus optional checkpoint capabilities. A pinned SDK helper owns backend operations; the existing Worker, Session lock and allocation receipts own admission and recovery. Unknown operations are observed rather than replayed, and work waits for authenticated resume.

Validation:

• Full make check passed after the single-provider revision (079c07d), including all 73 Web cases, PostgreSQL tests, generated SQL checks and the Linux SDK helper.
• Deployment and lifecycle race tests cover maintenance admission, preserved retries, refused switching with live/suspended/cleanup/unknown resources, unchanged ownership and startup rejection before backend effects. Deployment fixtures use isolated databases without bypassing production guards.
• Earlier real Linux/KVM qualification preserved a live RAM challenge and reclaimed source memory; the production helper passed two snapshot cycles. Core + Codex 0.153.4 + real Kimi K3 completed two Turns across suspension and Core restart, preserving history/files/configuration and one-time initialization. Public file upload/listing also woke the retained Session. This native/backend evidence predates the configuration revision; no new real-model run is claimed for that revision.

A fresh independent reviewer checked the entire diff against fd23f169 under the latest requirements and found no substantiated in-scope issues. Its focused adapter, daemon and PostgreSQL tests passed.

Deployment requires Linux amd64, KVM and native Core/helper under a private service account; deploy matching daemon wire 0.5.0. Legacy retained allocations without a recorded backend identity must be cleaned through the previous Core/configuration before initial adoption. Single-sample POST-to-Turn-start latency was 27.015 seconds for creation and 21.797 seconds for resume, not a p95 or Docker speed comparison.

The current sessions CI run passed Go tests and reached an unchanged official-client assertion also failing on baseline fd23 and main. It still expects supported multi_agent.enabled=true to be rejected. No checks were weakened; its later container step did not run. GitHub check and native-build passed for the current revision.

Design, acceptance and issue register (Document A)