feat(proxy): deliver an explicit-workspace TLS-passthrough discovery consumer #4954

Parent: #4669 (supported discovery-driven sandbox proxy). Dependencies: #4941 and authoritative application URL publication.

User Story

I use OpenShell to expose sandbox applications through independent ingress. I need a deployable reference consumer of service discovery that routes application connections directly to the owning supervisor.

Problem Statement

The discovery API alone does not route public application connections. The initial explicit-workspace proxy can be reviewed independently of discovery-only platform credentials and all-workspaces discovery.

Impact / Why This Matters

Operators otherwise implement their own SNI routing, expiring caches, withdrawal handling, and packaging before using the independent application path.

Proposed Design

Provide an optional TLS-passthrough proxy with exact discovered-host routing, bounded caches and connections, expiring routes, stream withdrawal, diagnostics, container/release packaging, and a standalone Helm chart. Use an existing identity authorized for one explicit workspace. Discovery-only grants and all-workspaces aggregation remain #4668; load qualification and the remaining full proxy acceptance criteria remain #4669.

Suggested UX

openshell-sandbox-proxy \
  --gateway-endpoint https://gateway.example.com \
  --workspace default \
  --gateway-ca /run/discovery/ca.crt \
  --discovery-token-file /run/discovery/token \
  --listen-address 0.0.0.0:8443

Acceptance Criteria

• HTTP and WebSocket TLS streams reach the discovered supervisor without gateway payload relay.
• Missing/unknown SNI, expired routes, and exhausted limits cannot dial a backend.
• Withdrawal, installation replacement, expiry, and authorization loss close affected streams.
• Reconnection reloads credential/trust files and relists routes with bounded retry behavior.
• Health/readiness/metrics and documented connection/cache limits are available.
• Standalone Helm and release/image packaging are included without Kubernetes API permissions.
• Tests and live dedicated-supervisor validation demonstrate routing and expiry behavior.

Alternatives Considered

An existing ingress with its own discovery adapter is supported. The reference proxy is optional. Gateway relay retains application load in the control plane; middleware and providers do not implement the required stream router.