[awf] Wire Cloud Hypervisor enclave execution through the trusted broker

[lpcox]

Goal

Connect the existing ADR 0002 host executor protocol/backend to enclave runtime selection and broker invocation so configured static Cloud Hypervisor enclaves can execute as one-shot VMs.

Contract

• Preserve host-executor protocol v2 exactly: one AWF-owned authenticated private Unix socket per run, existing framing/capability/replay/settlement behavior, and closed request/response shapes. Do not expose a new public transport or accept launch controls from the broker.
• The AWF control process owns listener construction, trusted run state, host paths, artifact verification, and the backend. The broker receives only the private client capability/channel required by the existing design; neither primary agent nor guest receives it.
• Runtime selection is explicit and fail-closed. enclaves[].runtime: cloud-hypervisor must never fall back to Docker, gVisor, sbx, or the primary-agent Cloud Hypervisor runtime.
• Initial user-facing support is limited to static script and static agent enclaves. Dynamic agent admission and custom image overrides remain rejected.
• A VM may be admitted only after supported-host/artifact preflight and availability of the hard-bounded writable-storage contract in [awf] Enforce per-invocation storage limits for Cloud Hypervisor enclaves #9394. Missing prerequisites, unsupported mixed runtime combinations, or cleanup/recovery uncertainty fail closed.
• Preserve current Docker/gVisor behavior and current primary-agent Cloud Hypervisor behavior.

Scope

Construct and close the per-run host executor listener at the correct AWF lifecycle boundary; connect the enclave MCP server's existing client; derive the host executor run state only from validated config and staged seeds; route explicit Cloud Hypervisor enclave selections to the one-shot backend; and retain existing cancellation, settlement, shutdown, and admission-drain semantics. Update runtime/config docs and targeted tests.

Acceptance criteria

• Static script and agent requests traverse the broker -> authenticated host socket -> trusted backend -> one-shot VM path on a supported GitHub-hosted Ubuntu x86_64 KVM runner.
• Negative tests cover invalid/missing capability, replay/conflict, wrong entry/executor kind, unsupported dynamic/image config, missing prerequisites, and startup/shutdown failures; rejected requests cause no VM/resource side effect.
• No request field can choose a command, path, mount, env, endpoint, image, limit, or runtime setting; these remain host-derived.
• Cancellation, timeout, settlement, admission closure, and cleanup/recovery retain ADR 0002 semantics.
• Unavailable Cloud Hypervisor execution returns an explicit failure and never starts a different runtime.

Coordination contract

This issue owns orchestration, listener/client wiring, and user-facing selection, not the implementation of bounded storage or the KVM conformance workflow. Consume the bounded-storage provider from the storage issue; do not implement an alternate capacity check. KVM tests can be authored concurrently against the unchanged protocol v2 and role-profile contracts, then run end-to-end once this wiring and bounded storage are available.

See ADR 0002, host executor protocol, and unified enclave architecture.