chore(helm): evaluate application-listener Gateway API configuration #5075

User Story

We are validating RFC 0017 on Kubernetes with the reference sandbox proxy and a separate example HTTPRoute controller. We need a clear way to configure the application ingress Gateway independently of the OpenShell control API Gateway.

Description

Examine Helm support for an application-listener-specific Kubernetes Gateway API frontend. The current chart's grpcRoute.gateway settings configure the control API's GRPCRoute and optional Gateway. Enabling the supervisor application listener does not configure an application ingress Gateway or its wildcard listener.

Decide which chart or documented integration should own this bootstrap configuration, and whether optional chart-managed application Gateway resources are useful alongside a separately managed Gateway. Keep application traffic directed to a discovery consumer or discovered supervisor endpoints. Keep dynamic per-service reconciliation outside the compute driver and preserve discovery as the integration boundary.

Cover both supported shapes:

• TLS passthrough to the reference openshell-sandbox-proxy, using a static wildcard route and supervisor TLS termination.
• HTTPS termination at an operator-managed Gateway, with an external discovery consumer reconciling HTTPRoutes and validated TLS backends to supervisor listeners.

This work examines deployment configuration. It does not promote the example Kubernetes controller to production or require bundling it into the OpenShell chart.

Context

• RFC 0017: rfc/0017-sandbox-service-exposure/README.md.
• Related listener and proxy work: feat(supervisor): add an independent sandbox application listener #4666, feat(proxy): add an optional discovery-driven sandbox application proxy #4669, feat(proxy): deliver an explicit-workspace TLS-passthrough discovery consumer #4954.
• The existing grpcRoute.gateway.create, name, namespace, and sectionName settings are scoped to the control API. feat(helm): support shared agentgateway Gateway #3715 covers shared agentgateway attachment for that API.
• Application hostnames, certificate coverage, public origin, listener attachment, and DNS bootstrap must agree. The application API can remain private while application ingress is public.

Suggested UX

Illustrative configuration for discussion; field names and the owning chart remain to be decided:

applicationIngress:
  gateway:
    create: false
    name: applications
    namespace: ingress
    sectionName: apps

An opt-in managed Gateway option, if selected, should have its own application listener/TLS settings and preserve platform-managed Gateway attachment. Document DNS, certificate, source-range, and reserved-address prerequisites without assuming a particular infrastructure provider.

Definition of Done

• Record whether OpenShell's chart, the optional proxy chart, or documented external manifests should own application Gateway bootstrap resources.
• Define how operators select a separately managed Gateway and application listener independently of grpcRoute.gateway.
• Evaluate optional chart-owned application Gateways and safe defaults when application ingress is disabled.
• Describe both proxy TLS passthrough and external HTTPRoute-controller integration, including TLS trust and DNS responsibilities.
• Ensure the proposed flow does not relay application payloads through the OpenShell control API.
• Identify follow-up implementation, Helm rendering, documentation, and Kubernetes E2E coverage.