Support multiple ordered sandbox pools per installation

Start with services/core/internal/deployment/placement/placement.go and the contracts/agents-api/sandbox-deployment.md contract, then trace the runtime_deployment schema and deployment API. The proposal spans placement, lifecycle, API, client validators, and Web, with open design questions still unresolved. Done means ordered pools replace the singleton across these areas while preserving the stated placement and restore constraints.

Problem

An installation can select exactly one Sandbox Provider (docker, microsandbox or e2b). Administrators cannot combine compute sources, for example Docker nodes plus microsandbox nodes, or self-hosted nodes that overflow to E2B. Switching providers requires a full sandbox reset that clears all hosted resources.

Multiple nodes of the same provider already work: DecidePlacement picks an online, ready node with free capacity, preferring the highest ready generation and then the fewest active sandboxes.

Where the single-provider assumption lives

• Contract: contracts/agents-api/sandbox-deployment.md says PostgreSQL holds "one active selection per installation", provider is "exactly one of docker, microsandbox, e2b", and changing to a different backend requires a reset first.
• Schema: runtime_deployment is a singleton table (singleton boolean PRIMARY KEY CHECK (singleton)) holding one provider_kind, mode, generation and specification. runtime_deployment_generations keeps retained generations only so that existing allocations can still be cleaned up.
• Placement: services/core/internal/deployment/placement/placement.go returns no placement in direct mode and otherwise chooses among the nodes of the single provider.
• Node configuration: providers.Load rejects configuring both docker and microsandbox ("only one sandbox provider can be configured").
• API and Web: /core/v1/sandbox/deployment GET/POST/PUT take one selection object, and SandboxSetupWizard asks the administrator to pick one provider.

Proposal

Replace the singleton deployment with an ordered list of sandbox pools. Each pool has its own provider, specification, Runtime release, generation, credential and priority.

• Data model: pools replace the runtime_deployment singleton. Placements and allocations record their pool, including direct (E2B) allocations, which have no placement record today.
• Placement: try pools in priority order and use the first one with admissible capacity. Within a node pool, keep the current node selection rules. Direct pools need a declared capacity limit so that lower-priority pools can be reached.
• Lifecycle: generation rollout, reset, owner epoch, suspension policy and node enrollment become per-pool. Removing or replacing a pool clears only that pool's resources.
• API and contract: replace the single deployment object with pool CRUD and ordering under /core/v1/sandbox/. Update the OpenAPI, sandbox-deployment.md and its zh translation, and the @oac/agents-client validators.
• Web: show a pool list with add, reorder, and per-pool nodes and capacity.

Constraints

• Ordering applies only when a new Session is placed, based on capacity and availability. A failed or unknown Create is never retried in another pool: the Sandbox Provider contract forbids replaying Create, and Core never substitutes another implementation.
• An existing placement, allocation or suspended Environment stays in its original pool and node. Restores never move to another pool.
• No provider-name branches in placement or lifecycle code. Pool behavior comes from the registered adapter declarations.
• Pre-release: replace the singleton outright, with no compatibility layer for the old single-deployment API.

Open questions

• Should a pool's capacity limit be declared by the adapter, set by the administrator, or both?
• Can pools of the same provider kind coexist, for example two E2B pools with different templates?
• How should Session-level selection (for example, by resources or Harness) interact with pool order, if at all?