[Epic] Integrate and qualify NemoClaw on OpenShell Kubernetes and multi-tenancy

## Outcome

NemoClaw integrates with and qualifies OpenShell’s supported Kubernetes deployment and multi-tenant workspace model. The qualified configuration pins an accepted OpenShell release and demonstrates supported NemoClaw agent workflows across multiple isolated tenants without reimplementing OpenShell’s Kubernetes runtime or tenant-isolation controls.

## Scope

- Select and pin an OpenShell release that provides the required Kubernetes deployment and multi-tenant workspace capabilities.
- Integrate NemoClaw with OpenShell’s official Helm chart, Kubernetes driver, Agent Sandbox dependency, and supported workspace-isolation model.
- Select one Kubernetes distribution, version, and cluster topology for initial qualification, documenting the required GPU runtime, storage, ingress, identity, secrets, and administrator-access assumptions.
- Provide the NemoClaw-specific configuration, policies, images, onboarding, documentation, and end-to-end validation required by the qualified deployment.
- Validate supported NemoClaw agent workflows across multiple OpenShell workspaces used as tenant boundaries.
- Validate permitted tenant-local operations and denied cross-tenant access across identity, credentials, policy, inference, telemetry, runtime state, recovery, and cleanup.
- Publish the qualified configuration, support boundary, operational responsibilities, limitations, troubleshooting guidance, and reproducible evidence.

## Acceptance criteria

- [ ] The qualified deployment pins an OpenShell release that provides the required Kubernetes and multi-tenant workspace capabilities.
- [ ] The Kubernetes distribution, version, cluster topology, GPU runtime, storage, ingress, identity, secrets, and administrator-access requirements are documented.
- [ ] NemoClaw installs and operates through OpenShell’s supported Kubernetes deployment path without a NemoClaw-specific Kubernetes runtime.
- [ ] The qualification deployment provisions at least two independently addressable OpenShell workspaces using OpenShell’s supported tenant-isolation model.
- [ ] Each qualification workspace has separate identity and authorization, credentials, policy, inference access, telemetry, and lifecycle scope.
- [ ] One workspace cannot read, mutate, route through, recover, or delete another workspace’s resources or secrets.
- [ ] Cross-tenant denial tests cover API access, sandbox operations, credentials, network paths, inference routes, logs, metrics, recovery, and cleanup.
- [ ] At least one supported NemoClaw agent workflow completes successfully in each qualification workspace.
- [ ] Installation, upgrade, recovery, and removal preserve the OpenShell isolation boundary and produce reproducible evidence.
- [ ] Documentation clearly distinguishes OpenShell-owned capabilities from NemoClaw integration and qualification responsibilities.

## Relationships and boundaries

- OpenShell owns Kubernetes sandbox provisioning, workspace identity and authorization, credential and resource isolation, and workspace-to-namespace enforcement.
- NemoClaw consumes, configures, and qualifies those capabilities for supported NemoClaw agent workflows.
- NVIDIA/OpenShell#1719, NVIDIA/OpenShell#1722, NVIDIA/OpenShell#1795, and NVIDIA/OpenShell#1678 represent upstream design or implementation dependencies.
- Missing upstream capabilities remain OpenShell dependencies and do not become NemoClaw implementation scope.
- NemoClaw #2218 retains broader air-gapped, restricted-network, K3s, and multi-host deployment guidance.
- NemoClaw #8504 owns the selected Enterprise AI reference-stack composition and may consume this qualified deployment path.
- This Epic does not create a NemoClaw-specific tenancy layer as a substitute for incomplete OpenShell functionality.
- This Epic does not claim support for every Kubernetes distribution, multi-cluster operation, or hosted control-plane topology.