[P1] Add provider-neutral isolated Agent runtime execution

[0YHR0]

Problem

Trusted Runtime Extensions execute inside the API process. That is acceptable for built-in or
operator-reviewed code, but it is not a safe execution model for third-party Agent runtimes,
untrusted capability scripts, or concurrent rollouts.

Proposal

Add a provider-neutral Isolated Execution Provider behind Managed Agent Runtime API. Support
profiles instead of one hard-coded backend:

• trusted-in-process for explicit built-ins;
• local-subprocess as the first isolated implementation;
• oci-container as the production-oriented next provider;
• remote-a2a for independently operated Agents.

Profiles declare filesystem, network, process, CPU, memory, deadline, credential, and Artifact
access policy. The control plane stores opaque execution handles and reconciles provider state.

Acceptance criteria

• Runtime capability discovery includes supported isolation and recovery features.
• Local subprocess execution has a separate working directory, bounded environment, timeout,
  cancellation, logs, and output collection.
• No database URL or unrelated secrets enter the child environment.
• Provider restart/reconnect and orphan cleanup are idempotent and audited.
• Sibling Runs cannot share writable workspace state by default.
• Runtime Extension status clearly distinguishes trusted-in-process from isolated/remote.
• Security documentation states guarantees and known OS limitations without claiming a sandbox
  stronger than implemented.
• The design can host [Proposal] Add first-class rollout groups for isolated, concurrent, verifiable agent execution #26 rollout-group executions without changing Run/Attempt identity.

Non-goals

• Building a Kubernetes scheduler.
• Making OCI mandatory for local development.
• Treating process separation alone as a complete hostile-code sandbox.

Dependencies

Blocked by Managed Agent Runtime API v0.1; coordinated with #26.