test(e2e): add split gateway/workspace Helm topology coverage #5016

User Story

I develop and test OpenShell and need E2E coverage for independently installed gateway and workspace charts. While working on #4873, the split-workspace test fixture was reverted to preserve the existing combined-chart Kubernetes coverage. I need both deployment topologies exercised so changes to the standalone workspace chart are validated before release.

Problem Statement

The Kubernetes E2E path in #4873 uses the combined gateway chart and its bundled workspace resources. It does not exercise the independently installed openshell-workspace chart with workspaceResources.enabled=false on the gateway release.

The reverted changes installed a separate workspace release and switched the default shared-mode runs and focused update task to that fixture. Add dedicated split-workspace coverage as a follow-up while retaining the combined-chart lane.

Impact / Why This Matters

The two charts maintain separate namespace-scoped RBAC and network-policy resources. Combined-chart tests can pass while a standalone workspace installation is missing permissions or has incorrect gateway ServiceAccount bindings. Sandbox configuration updates are one concrete example: their preflight needs Pod reads and listing to detect remaining workload or supervisor Pods.

Today, this topology requires manual deployment validation. Rendered-chart tests alone do not demonstrate that the gateway can create, use, stop, update, restart, and delete a sandbox through the independently installed workspace resources.

Proposed Work

Add a reproducible E2E lane for the documented split gateway/workspace deployment:

• Install the gateway with bundled workspace resources disabled and install openshell-workspace independently in a distinct sandbox namespace.
• Configure the gateway namespace, ServiceAccount identity, sandbox namespace, and network-policy selectors consistently.
• Exercise the normal sandbox lifecycle and reuse the configuration-update scenarios introduced by feat(sandbox): support storage-preserving sandbox configuration updates #4873, including retained identity, PVC contents, and updated command/environment behavior after restart.
• Expose an explicit local task and CI selection for this topology. For example, a proposed mise run e2e:kubernetes:split-workspace task could select it; the final command name can follow existing task conventions.

Acceptance Criteria

• The split topology runs locally and in CI as an additional, explicitly identified lane; existing combined-chart coverage remains enabled.
• The fixture uses separate gateway and workspace releases in distinct namespaces, with workspaceResources.enabled=false on the gateway release.
• Tests rely on the workspace chart's intended permission grants and network policy, without extra broad permissions masking missing chart resources.
• Sandbox creation, connectivity, stop/start, and deletion succeed through this topology.
• The configuration-update tests from feat(sandbox): support storage-preserving sandbox configuration updates #4873 pass, including stopped-only admission, preserved sandbox/CR/PVC identity and stored contents, and the updated command/environment on the next start.
• Both Agent Sandbox API-version lanes supported by the existing Kubernetes E2E tasks are exercised.
• Fixture cleanup removes resources it owns after success or failure, and failures retain useful diagnostics.
• Contributor documentation and the Helm development skill explain how to select and reproduce the split-workspace lane.

Context and Alternatives

• Follow-up to feat(sandbox): support storage-preserving sandbox configuration updates #4873; the topology switch was reverted in 79ce7970c (ci: restore combined-chart Kubernetes e2e coverage). This task adds coverage without replacing the combined-chart tests.
• The split-chart deployment was introduced by feat(helm): split gateway and workspace namespace charts #2485 and is documented in docs/kubernetes/setup.mdx under “Split gateway and workspace releases.”
• Relevant implementation surfaces: e2e/with-kube-gateway.sh, e2e/rust/e2e-kubernetes.sh, tasks/test.toml, .github/workflows/e2e-kubernetes-test.yml, and tests/suites/features/kubernetes-updates/.
• Helm render tests remain useful, but do not replace exercising the deployed RBAC and network-policy behavior. This is deployment-test coverage; middleware, interceptors, and providers do not supply that coverage.