feat: serve Kubernetes sandbox sessions from the experimental shared supervisor #4700

User Story

I am prototyping OpenShell multi-tenant supervision on Kubernetes and want the existing feature-flagged supervisor Deployment to serve multiple sandboxes from the same gateway, without HA or autoscaling.

Problem Statement

The experimental gateway supervisor currently has only process health. The runtime-initiated listener is pinned to one sandbox, and Kubernetes lifecycle and readiness still assume a dedicated supervisor Pod per sandbox.

Impact / Why This Matters

An end-to-end opt-in shared supervisor is needed to validate the design with multiple independently governed sandboxes before extending it to other drivers.

Proposed Design

Under the existing Kubernetes gateway topology experiment, one shared supervisor accepts independently authenticated sandbox sessions across shared, managed, and operator workspace namespace modes. Existing generations keep dedicated supervision. Session admission is gateway-authorized, incoming runtime connections are routed to the expected generation and authenticated, and stopping one sandbox removes only its session. Preserve fail-closed disconnect behavior. HA, autoscaling, placement, rebalancing, and transparent takeover are outside this increment.

Suggested UX

gatewayConfig:
  openshell.drivers.kubernetes:
    experimental_supervisor_topology: gateway

Acceptance Criteria

• Two concurrent sandboxes use the shared supervisor with independent policies and credentials.
• Unknown, stale, and mismatched session identities fail authentication without affecting other sessions.
• Sandbox readiness is session-specific and provisioning avoids waiting on gateway state not yet persisted.
• Stop/delete/restart affects only the targeted session; existing dedicated generations remain supported.
• Shared, managed, and operator workspace modes have suitable routing and NetworkPolicies.
• Relevant existing sandbox E2E and a focused multi-sandbox isolation scenario pass.

Alternatives Considered

A process-per-sandbox Deployment retains the existing topology. Middleware and interceptors do not provide runtime connection routing, authenticated session admission, or Kubernetes lifecycle integration.