feat(k8s): support configuring workspace PVC storageClassName

[loveRhythm1990]

Summary

The Kubernetes compute driver's default workspace PVC never set storageClassName, so on clusters with no default StorageClass the PVC stayed Pending and sandbox creation failed. This adds a driver-level workspace_storage_class option so operators can pin the workspace PVC to a specific StorageClass.

Related Issue

Closes #2442

Changes

• Add workspace_storage_class: String to KubernetesComputeConfig (empty default preserves current behavior — omit storageClassName, use the cluster default StorageClass).
• Thread it through SandboxPodParams into default_workspace_volume_claim_templates(), setting storageClassName on the generated PVC only when non-empty.
• Read OPENSHELL_K8S_WORKSPACE_STORAGE_CLASS in the standalone driver main.rs, mirroring the existing storage-size env var.
• Expose server.workspaceStorageClass in the Helm chart (values.yaml + gateway-config.yaml), regenerate the chart README.md via helm-docs.
• Document the field in docs/reference/gateway-config.mdx and docs/reference/sandbox-compute-drivers.mdx.
• Add a sandbox-PVC-pending troubleshooting row to the debug-openshell-cluster skill.

No proto/gRPC change — this is a driver-level default at the same granularity as the existing workspace_default_storage_size.

Testing

• mise run pre-commit passes (one pre-existing, unrelated failure in openshell-supervisor-network::test_forward_public_ip_allowed_without_allowed_ips — an environment DNS-interception flake that also fails on clean main; untouched crate)
• Unit tests added/updated — new tests cover storageClassName set when provided and omitted when empty (driver.rs), plus config default/serde-override (config.rs)
• E2E tests added/updated (if applicable) — not run here; change is covered by unit tests and verified via helm template rendering both with and without the value set

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable) — user-facing docs + Helm README + debug skill updated

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[giladk1221]

we really need this fix and would greatly appreciate your help in pushing it forward.

• CC @orsharon7

[drew]

/ok to test 9a705b3

[drew]

gator-agent

PR Review Status

Validation: This PR is project-valid because it implements the maintainer-triaged Kubernetes workspace PVC storageClassName request from #2442 with a bounded driver, gateway config, Helm, and docs change.
Head SHA: 9a705b3f4b639620e08862d4bc4d60f14a80a8d0

Review findings:

• No blocking findings remain. The independent code-only reviewer reported no actionable findings for this patch.

Docs: Fern reference docs and the Kubernetes driver documentation were updated for the new workspace_storage_class / server.workspaceStorageClass setting.

Tests: Unit coverage was added for config defaults/serde and PVC generation with set and empty storage classes. Because this changes Kubernetes driver behavior and Helm-rendered gateway config, test:e2e and test:e2e-kubernetes are required.

Next state: gator:watch-pipeline

[drew]

/ok to test 9a705b3

[github-actions]

Label test:e2e applied for 9a705b3. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[github-actions]

Label test:e2e-kubernetes applied for 9a705b3. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute Kubernetes HA E2E after building the required gateway and supervisor images once. This is an optional proof-of-life suite; failures are visible in the workflow run but do not publish a required CI gate status.

[github-actions]

Label test:e2e-kubernetes applied for 9a705b3. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute Kubernetes HA E2E after building the required gateway and supervisor images once. This is an optional proof-of-life suite; failures are visible in the workflow run but do not publish a required CI gate status.

[loveRhythm1990]

Thanks for running the Kubernetes e2e. I've seen the kubernetes-ha-e2e failure and I'm looking
into it.

A few notes on where things stand:

• The failures are all sandbox pods never reaching Ready — either stuck Pending
  (DependenciesNotReady: Pod exists with phase: Pending) or a running pod whose supervisor never
  relays back (supervisor session not connected / ssh 255). They surface only as CLI timeouts, since
  the HA e2e doesn't currently capture pod/PVC/controller diagnostics on failure.
• The high-availability overlay runs the gateway with replicaCount: 2 behind a single Service, so
  I suspect a multi-replica session-routing issue (the supervisor relay landing on a different
  replica than the one holding the session) rather than anything storage-related.

I'm planning to reproduce this locally with the HA values (ci/values-high-availability.yaml + the
external Postgres fixture) to confirm the root cause. I'll report back with findings.