feat(sandbox): add sandbox-initiated supervisor connections with legacy compatibility #4652

User Story

The requesting OpenShell operator is developing the shared-supervisor prototype in #4429 and directly needs a separate prerequisite change: newly created sandboxes should initiate their protected control connection to the supervisor, while existing sandboxes continue using their original connection direction. The operator explicitly requested preserving existing sandboxes rather than requiring a fleet recreation.

Problem Statement

The supervisor currently initiates the Sandbox Protocol connection to a listener in the sandbox runtime. There is no sandbox-initiated transport, nor a persisted per-sandbox choice that permits both directions to coexist through upgrades.

Impact / Why This Matters

The current connection direction couples runtime reachability and future shared-supervisor/identity work. Replacing it globally would risk disrupting already-running sandboxes and changing the behavior of existing sandboxes after stop/start. This prerequisite should land independently of the shared-supervisor prototype.

Proposed Design

Add a sandbox-initiated control connection for newly created dedicated Kubernetes sandboxes. Keep the current sandbox execution, authorization, mediation, and reconnect behavior. Existing sandboxes without a recorded transport choice retain supervisor-initiated connections; their choice survives stop/start and gateway/supervisor restarts. Both transports work concurrently in one installation. Deploy dual-mode binaries before enabling the new creation default. Other compute drivers retain their current transport for this first change.

Suggested UX

Existing CLI operations remain unchanged:

openshell sandbox create --name new-sandbox --detach
openshell sandbox exec new-sandbox -- echo connected
openshell sandbox stop existing-sandbox
openshell sandbox start existing-sandbox

The new sandbox initiates its protected connection. The existing sandbox retains its legacy transport, including after restart. This does not require a new workload-policy field or an operator-managed migration command.

Acceptance Criteria

• Newly created dedicated Kubernetes sandboxes initiate the protected supervisor connection.
• Existing sandboxes, including records lacking transport metadata, retain their legacy behavior across stop/start and gateway/supervisor restarts.
• Legacy and new-mode sandboxes operate together in the same namespace with exec, file transfer, and network policy enforcement intact.
• Connections authenticate exact sandbox/generation/session identity; misidentified, duplicate, stale, and unauthenticated connections cannot acquire control.
• Reconnection retains the current same-supervisor recovery contract, never repeats workload launch or commands, and fails closed on enforcement loss.
• The new network path is narrowly fenced; creating a new-mode sandbox does not mutate existing sandboxes' recorded network-fence identity or grant them direct egress.
• Unsupported peer versions are detected before selecting a new-only transport; compatibility and rollback limits are documented.
• Relevant unit, mixed-mode integration, and real Kubernetes E2E checks pass; deployment guidance is updated.

Alternatives Considered

• Globally reverse all existing connections: fails the requested compatibility behavior.
• Rewrite the complete gRPC command protocol while changing direction: larger than the required prerequisite; keep RPC semantics when feasible.
• Implement this only inside the HA prototype: prevents independently reviewing and landing the transport prerequisite.
• Gateway middleware, interceptors, or credential providers: these do not control the trusted sandbox-runtime connection and cannot satisfy the requirement.

Agent Investigation

The existing supervisor uses a custom gRPC connector, and the runtime can serve its protocol over a supplied byte stream. This permits reversing connection establishment while retaining protocol roles. The current Kubernetes workload fence denies new outbound connections, so coexistence requires a narrowly scoped new-mode network path rather than editing the old fence in place.