[Feature] Kubernetes sandbox backend using kubernetes-sigs/agent-sandbox

Problem

The app server picks its sandbox backend from RUNTIME, and today that is docker, remote, or local/process. Docker is a single host. The remote backend talks to a runtime API that someone has to operate, so it is not self-hostable. That leaves nothing for a team already running Kubernetes who wants the app server to put each sandbox in a pod the cluster manages. The options are running Docker inside a pod, or building a service that implements the runtime API contract in front of their own cluster.

kubernetes-sigs/agent-sandbox is a Kubernetes SIG project that models this exact workload as a CRD: a single pod, stateful, isolated runtime with a claim based lifecycle, pause and resume that keeps a persistent volume, and optional gVisor or Kata isolation through runtimeClassName.

The agent server is already an image listening on a port, and kubernetes is already a dependency of this repo, so this needs no changes to the agent server and no new packages.

Proposed behaviour

A KubernetesSandboxService selected with RUNTIME=kubernetes, implementing the existing SandboxService contract:

• each sandbox is a SandboxClaim, and the controller turns that into a Sandbox and a pod running the agent server
• status is derived from the Sandbox conditions and operating mode, so the app server stores nothing of its own and the cluster stays the source of truth, the same way the docker backend treats the docker daemon
• the sandbox URL is built from the Sandbox resource name, which cluster DNS resolves
• every sandbox gets its own session API key
• pause and resume set spec.operatingMode, so the pod is removed and the volume is kept
• a matching spec service, so several pools can be offered as selectable runtimes

Along with deployment manifests for the template, the pool and RBAC, and documentation that covers the browser facing URL case and the network policy.

Acceptance criteria

• RUNTIME=kubernetes selects the backend and nothing else in the app server changes
• The full SandboxService contract works against a real cluster: create, search, get, look up by session key, pause, resume and delete
• Pausing suspends the pod and keeps the volume, and resuming brings the same sandbox back
• A sandbox answers on its own session API key and rejects a request without it
• Unit tests cover the backend with the Kubernetes client mocked
• Verified end to end on a local cluster and on a cloud cluster

Alternatives considered

• Running Docker inside a pod. Keeps the docker backend, but gives up the Kubernetes lifecycle and weakens isolation.
• Putting a service in front of the cluster that implements the hosted runtime API contract, then using the existing remote backend. Needs no change here, but it means operating another service and reimplementing a contract you do not own.
• Leaving it to deployment tooling. Does not help, because the app server still has to create and track a sandbox somehow.

Known limitation

Warm pools do not help yet. agent-sandbox cold starts any claim that carries spec.env, and the app server always sets webhook and port variables there as well as the session key. The pool therefore ships with replicas: 0 and the deployment README says so. Letting a claim adopt a warm pod and receive its configuration afterwards is tracked upstream in agent-sandbox#1480. When that lands, the only change needed here is raising the replica count.

Start by reading the existing SandboxService contract and the RUNTIME backend selection, then inspect the deployment manifests and deployment README requirements for the template, pool, RBAC, URL case, and network policy. Add the Kubernetes backend with mocked-client unit tests, then verify the listed lifecycle, authentication, pause/resume, and cluster checks against local and cloud clusters.