feat(helm): split gateway and workspace namespace charts #2485

Problem Statement

OpenShell now supports three Kubernetes workspace namespace modes through RFC
0011 and #2656:

• shared: all workspaces use one configured namespace;
• managed: the gateway creates and deletes a namespace per workspace; and
• operator: each workspace maps to a pre-provisioned namespace discovered by
  label selector or allowlist file.

The remaining gap is Helm packaging and lifecycle ownership. The repository
still publishes one deploy/helm/openshell chart that combines the gateway
control plane with namespace-local sandbox prerequisites. Platform operators
therefore cannot install and upgrade one shared gateway independently from the
sandbox ServiceAccount, Role, RoleBinding, and NetworkPolicy owned by each
pre-provisioned application or tenant namespace.

This makes delegated workspace onboarding and GitOps ownership harder even
though the runtime can now map workspaces to multiple operator-managed
namespaces.

Proposed Design

Provide two independently installable and version-aligned charts while keeping
the current combined installation backward compatible:

1. Gateway chart (helm-chart)
   • Continue to deploy the gateway workload, Service, configuration,
     PKI/database hooks, gateway ServiceAccount, and required cluster-scoped
     runtime permissions.
   • Add a backward-compatible value such as
     workspaceResources.enabled=false that omits resources owned by a
     workspace namespace.
   • Keep the existing default (true) so current installations render the
     same topology.
2. Workspace chart (openshell-workspace)
   • Install once in each platform-managed application or tenant namespace.
   • Create only the sandbox ServiceAccount, namespaced Role and RoleBinding,
     and namespace-local sandbox SSH NetworkPolicy.
   • Accept the shared gateway ServiceAccount name and namespace explicitly so
     a RoleBinding can authorize a subject from another namespace.
   • Never create a namespace, gateway workload, or cluster-scoped resource.
3. Release and documentation contract
   • Publish both OCI charts at the same OpenShell chart version.
   • Document one external namespace with shared mode and multiple
     pre-provisioned namespaces with operator mode.
   • Keep sandbox ServiceAccount naming aligned between the gateway and
     workspace releases.

Acceptance Criteria

• Default gateway-chart renders retain the current object identities and
  combined-install behavior.
• Gateway-only mode omits exactly the sandbox ServiceAccount, namespaced Role,
  RoleBinding, and NetworkPolicy.
• The workspace chart renders those four namespace-local resources and no
  gateway or cluster-scoped resource.
• A workspace RoleBinding can reference a gateway ServiceAccount in another
  namespace.
• Automated render tests prove the gateway-only and workspace releases do not
  claim the same Kubernetes object.
• Helm lint, generated documentation, unit tests, and OCI packaging cover both
  charts.

Scope Boundary

This RFE defines the chart and release ownership boundary. It does not change
Kubernetes driver namespace selection, operator allowlist behavior, namespace
lifecycle, or the cluster-wide watch/RBAC currently required by multi-namespace
runtime modes. Any redesign that replaces cluster-wide watches or further
attenuates operator-mode ClusterRole permissions should remain a separate
runtime/RBAC change.

Alternatives Considered

• Install the gateway chart once per namespace: duplicates gateways,
  credentials, database state, and lifecycle operations.
• Use only conditionals in one chart: can alter a render but does not provide
  an independently versioned tenant-onboarding artifact or clear GitOps
  ownership boundary.
• Use managed mode for all tenants: lets the gateway create namespaces and
  prerequisites dynamically, but conflicts with platforms where namespace
  lifecycle and policy must remain operator-owned.

Current Upstream Findings

• deploy/helm/openshell remains the only published chart.
• server.drivers.kubernetes.workspaceMode now supports shared, managed,
  and operator; feat(k8s): add namespace-per-workspace support (RFC 0011 Phase 3) #2656 delivered namespace-per-workspace runtime support.
• Shared mode renders a namespaced Role and RoleBinding. Managed/operator modes
  use the current ClusterRole model for multi-namespace access.
• The chart still owns the sandbox ServiceAccount and NetworkPolicy alongside
  the gateway release.
• RFC 0011 defines runtime namespace mapping, but not a separately published
  workspace chart or its release/ownership contract.

Implementation

PR #2643 implements this packaging boundary and preserves the current runtime
authorization model.

Checklist

• I've reviewed current chart templates, RFC 0011, feat(k8s): add namespace-per-workspace support (RFC 0011 Phase 3) #2656, and related
  Kubernetes runtime documentation.
• This is a design proposal, not a "please build this" request.