feat(proxy): add an optional discovery-driven sandbox application proxy #4669

• Parent: Sandbox Service Exposure #4310
• Dependencies: feat(gateway): publish accepted supervisor service routes for discovery #4667, feat(auth): authorize a discovery-only reader across all workspaces #4668.

User Story

I use OpenShell to expose sandboxed applications through a shared ingress. I need an optional supported router that follows service ownership without requiring a custom discovery adapter or carrying application payloads through the gateway.

Problem Statement

Operators with no existing discovery integration need a deployable consumer of the supervisor route API. A working listener and API alone do not route public application connections.

Impact / Why This Matters

Each deployment otherwise needs custom routing/cache logic, credential management, and packaging before it can use the independent application data plane.

Proposed Design

Provide an optional openshell-sandbox-proxy binary/image and Helm deployment. Read SNI, select an exact unexpired advertised route, and forward the TLS stream unchanged to its supervisor. Application TLS terminates at the supervisor.

Authenticate discovery using the machine discovery-reader grant introduced in #4668. Support all-workspaces discovery without adding general resource permissions. Reload credentials on reconnect, bound connections/setup/cache work, and close affected streams on withdrawal, replacement, authorization failure, or expiry. Application connections must not carry discovery credentials.

Include release builds/publishing, deployment readiness and diagnostics, and a reference Gateway API TLS-passthrough integration. Define retry/backoff, TLS renewal, and operational limits. An external ingress adapter remains supported.

Suggested UX

Illustrative proxy invocation after #4668 lands (the all-workspaces flag is proposed):

openshell-sandbox-proxy \
  --gateway-endpoint https://gateway.example.com \
  --all-workspaces \
  --discovery-client-cert /run/discovery/tls.crt \
  --discovery-client-key /run/discovery/tls.key \
  --gateway-ca /run/discovery/ca.crt \
  --listen-address 0.0.0.0:8443

Document explicit workspace selection as well. Retain mutually exclusive credential modes and prohibit credentials on plaintext development transport.

Acceptance Criteria

• HTTP and WebSockets route through TLS passthrough to the correct supervisor without gateway payload relay.
• Missing/unknown SNI and expired routes never dial a backend; cached routes follow withdrawals and replacements.
• The deployed proxy uses discovery-only credentials, with no operator certificate, user login, or provider credential access.
• All-workspaces discovery tracks workspace lifecycle within bounded resource limits.
• Credential renewal/reconnect, authorization failure, and discovery outages have automated integration coverage.
• Helm mounts only required discovery identity/server trust material, and provides documented readiness and NetworkPolicy behavior.
• Release automation builds and publishes the supported proxy image architectures alongside deployment documentation.
• Load tests show bounded proxy/supervisor resource use and responsive gateway/control operations while serving applications.

Alternatives Considered

An existing ingress plus discovery adapter is a supported alternative, so the proxy is optional. TLS termination at the proxy requires a different trusted HTTP/backend contract. Gateway relay retains application load in the control plane. Middleware/providers do not implement SNI routing and route ownership.

Agent Investigation

Include the proxy binary, container packaging, cache tests, Helm deployment, and release image workflows in this issue. Add client-CA, peer-identity, and backend TLS support where required for secure discovery and routing; keep this work independent of the listener implementation in #4666.