feat(auth): authenticate gateway-routed sandbox service requests #4722

• Parent: Sandbox Service Exposure #4310
• Dependencies: current main; independent of feat(supervisor): add an independent sandbox application listener #4666.

User Story

I run OpenShell sandboxes that include an addressable service. I want requests through the gateway to use gateway-mediated authentication and access controls, while retaining the independent app listener for operator-supplied data-plane authentication.

Problem Statement

Gateway service exposure needs an explicit authentication and authorization contract for application HTTP requests and WebSocket upgrades. Publishing a service must not implicitly make its gateway endpoint accessible without gateway authentication in an authenticated deployment.

Impact / Why This Matters

Operators need a gateway-managed access path without implementing gateway identity checks in every application. They also need a separate data-plane path that can use authentication suited to their own ingress or application.

Proposed Design

Authenticate gateway-routed service requests using the gateway's supported user identity mechanisms and enforce the appropriate workspace/sandbox access checks before connecting to an application. Define browser-compatible authentication and WebSocket upgrade behavior. Reject missing, invalid, expired, or revoked credentials before upstream dial.

Keep gateway identity material separate from application credentials. Define how gateway authentication coexists with application bearer passthrough and session cookies. Strip gateway credentials and gateway identity headers before forwarding; untrusted forwarded headers must not establish identity.

The supervisor app listener in #4666 remains an independently enabled path with operator-supplied data-plane authentication. It does not require or inherit gateway user authentication. Enabling it must not disable gateway ingress or weaken gateway access controls. Discovery-only machine credentials from #4668 must not grant application access.

Explicit unauthenticated local-development configurations may retain their documented behavior. Authenticated deployments require gateway authentication for gateway-routed application requests.

Suggested UX

Illustrative gateway-authenticated request:

curl --header "Authorization: Bearer ${GATEWAY_ACCESS_TOKEN}" \
  https://default--app-sandbox.gateway.example.com/

Document a browser login/session workflow and WebSocket support without exposing gateway tokens to applications. Document the app-listener path separately, with authentication provided by the operator's ingress or application.

Acceptance Criteria

• Gateway-routed HTTP and WebSocket requests require gateway authentication in authenticated deployments.
• Missing, invalid, expired, or revoked gateway credentials are rejected before any application dial.
• Workspace/sandbox authorization prevents authenticated cross-workspace access.
• Browser sessions and WebSocket upgrades have a supported authentication workflow with appropriate origin/CSRF protections.
• Gateway credentials never reach applications; application bearer credentials and cookies retain their documented behavior.
• Spoofed identity or forwarding headers cannot establish gateway identity.
• Discovery-only credentials do not grant application access.
• Gateway ingress works with the supervisor app listener disabled or enabled.
• App-listener traffic uses operator-supplied authentication without requiring gateway user credentials.
• Explicit local-development authentication exceptions are documented and tested.
• Automated integration/e2e tests cover both authentication boundaries and rejection before upstream dial.

Alternatives Considered

Application-only authentication remains appropriate for the independent app listener but does not provide gateway-mediated access control. An identity-aware edge can protect an operator's data plane but does not define the gateway service authentication contract. Separate gateway socket listeners in #4210 address network and TLS exposure; this issue covers request authentication and authorization.

Scope

Keep this work separate from #4666's app listener implementation. It adds no service discovery API, proxy, or public URL publication changes.