bug: driver-controlled runtimes do not apply live policy revisions

User Story

As an OpenShell operator, I want policy updates accepted for a running sandbox to be applied live by its active compute runtime, so that the policy reported by the gateway always matches the policy the workload is actually enforcing.

Problem Statement

PR #2823 gives driver-controlled runtimes the canonical create-time policy in DriverSandboxSpec.policy and removes the MXC-specific rejection for live policy mutations. The MXC backend reads and maps that policy only during ValidateSandboxCreate and CreateSandbox; it does not fetch later revisions or report their load status.

The gateway can therefore accept and persist a later policy revision for a running driver-controlled sandbox without the runtime consuming it. The desired policy returned by the gateway then differs from the policy enforced by the workload.

The existing sandbox configuration contract already exposes later revisions through GetSandboxConfig and load acknowledgement through ReportPolicyStatus. This bug does not require a compute-driver reconcile RPC.

Impact / Why This Matters

A tightening update can appear accepted while the workload continues under the previous policy. A loosening update remains unavailable even though the gateway records it. --wait can time out because the driver never reports the revision as loaded.

The current workaround is to delete and recreate the sandbox so the policy is delivered again at creation. That interrupts the workload, discards runtime state, and violates the expected live policy-update workflow.

Acceptance Criteria

• A driver-controlled runtime without the standard supervisor observes every new effective policy revision for each running sandbox.
• The runtime applies supported live policy changes without deleting or recreating the sandbox.
• The runtime calls ReportPolicyStatus with the exact revision and reports loaded only after enforcement has switched to that revision.
• A load or enforcement failure is reported as failed and is visible through openshell policy status and --wait.
• A policy change the selected runtime cannot enforce live is rejected before it can be mistaken for an applied revision.
• Reconnects, gateway restarts, and temporarily missed notifications converge the runtime to the latest effective revision.
• Tests cover successful live application, rejected unsupported changes, failed application, acknowledgement, and catch-up after reconnect/restart.
• MXC documentation no longer claims live revision support unless the MXC runtime implements and validates this behavior.

Reproduction Steps

1. Build the Windows gateway from PR #2823 with the MXC driver enabled.
2. Create and start an MXC sandbox with a policy that the driver maps successfully.
3. Submit an otherwise valid live policy replacement or merge update with openshell policy set --wait or openshell policy update --wait.
4. Observe that the gateway persists the new revision, while MxcComputeBackend continues using only the policy captured during CreateSandbox and never acknowledges the later revision.
5. Observe that --wait cannot confirm the revision as loaded and the running workload remains governed by its create-time policy.

Environment

• OpenShell: PR #2823 at d26297a214b40809e4b4dfcd5513e3e257b0552c
• OS: Windows 11 Insider build supported by MXC
• Runtime, deployment, or integration: in-process openshell-driver-mxc, without the standard sandbox supervisor
• Verification note: identified through code review; native Windows execution was not available on the review host

Related Work

• #2417
• #2823

Start by tracing MxcComputeBackend through ValidateSandboxCreate and CreateSandbox, then inspect the existing GetSandboxConfig and ReportPolicyStatus contract. Use the reproduction steps and openshell policy status/--wait behavior to verify how revisions are delivered and acknowledged. Done means the listed live-application, failure, rejection, acknowledgement, reconnect, restart, and documentation cases are covered by tests.