Support prebound proxy listeners and per-connection identity #4804

User Story

I use OpenShell sandboxes to run agent workloads with executable-scoped network policies. When an isolation backend routes workload processes through the supervisor's explicit proxy, I need each connection attributed to the process that opened it. I also need the backend's launcher to retain its reserved listening socket until sandbox cleanup completes.

Problem Statement

The OpenShell supervisor's direct proxy configuration accepts a bind address and one static executable identity. The trusted supervisor setup for an isolation backend cannot supply an already-bound listening socket or a resolver that establishes a separate executable identity for each connection.

Impact / Why This Matters

Compute drivers whose isolation backends use this direct-listener path must currently assign every caller the same identity or maintain changes to the supervisor's proxy. A shared identity makes executable-scoped network policies and audit records less accurate. Releasing a reserved socket so the supervisor can bind it again creates a window for another process to claim the address.

These gaps make it harder for compute drivers and isolation backends to reuse the supervisor's network policy enforcement, TLS inspection and provider credential handling.

Proposed Design

An isolation backend's trusted supervisor setup can configure the OpenShell supervisor to serve a listening socket already reserved by the backend's launcher and resolve the executable identity of each connecting workload process. Operators continue authoring network_policies through the existing OpenShell policy workflow.

The supervisor evaluates each connection using the verified caller identity. If attribution is missing, ambiguous or fails, the supervisor denies the request and records an OCSF denial event. It does not substitute the configured static identity. The backend's launcher can retain its socket handle until sandbox cleanup completes, even if the supervisor closes its copy.

The compute driver continues to manage sandbox lifecycle, the isolation backend provides workload isolation, and the supervisor owns proxy authentication, network policy evaluation and provider credential handling. Existing static-identity listeners and isolation backends using transparent network mediation keep their current behavior. Incompatible listener settings fail at supervisor startup with a clear error.

Acceptance Criteria

• An isolation backend's trusted supervisor setup can supply its launcher's already-bound TCP listener without releasing and rebinding the address.
• Connections from different workload executables receive policy decisions and audit attribution based on their own verified identities.
• Missing, ambiguous or failed attribution denies the request and records an OCSF denial event without using a static fallback.
• The supervisor rejects a supplied socket with an unexpected bound address at startup.
• The supervisor rejects direct-listener settings combined with transparent network mediation.
• Closing the supervisor's socket copy leaves the backend launcher's retained reservation intact.
• Existing static-identity proxy and transparent network mediation flows continue to pass their relevant tests.

Alternatives Considered

• Use one static executable identity. This works when every proxy connection represents the same executable, but cannot distinguish multiple workload processes.
• Release and rebind the address. This lets the supervisor create its own listener, but breaks continuous ownership of the backend launcher's reservation.
• Use supervisor middleware, gateway interceptors or providers. These extension points inspect requests or manage credentials. They do not control the supervisor's listening socket or establish authoritative workload process identity at connection acceptance.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request