feat(sandbox): add gVisor runtime adapter

[drew]

Summary

Add a gVisor adapter beneath the existing OpenShell Sandbox Protocol so Kubernetes sandboxes can run with GKE Sandbox on COS nodes without relying on Landlock or seccomp user notification. The native Linux adapter remains the default and retains its existing enforcement model.

This PR is intentionally a reduced-fidelity backend: gVisor provides the workload boundary, Kubernetes NetworkPolicy provides zero direct egress, and proxy-aware HTTP/HTTPS traffic is mediated through an authenticated reverse tunnel.

Related Issue

Related to #3361.

Stacked on #3366; review and merge that PR first.

Changes

• Carry a native-linux or gvisor adapter choice through the protected runtime descriptor and bind confirmation evidence to the selected mechanism.
• Reuse OpenShellRuntimeBackend and the authenticated Sandbox Protocol while adding an explicit HTTP/CONNECT proxy stream for gVisor.
• Infer the adapter from an admitted Kubernetes Pod with runtimeClassName: gvisor, inject loopback proxy environment variables, and omit the seccomp profile and unprivileged-port sysctl that GKE Sandbox does not support.
• Use endpoint-only policy evaluation for gVisor because transparent TCP interception and trusted per-binary attribution are unavailable.
• Preserve native Landlock, seccomp-notify, transparent TCP, DNS mediation, and binary attribution behavior.
• Document the operational model and limitations in the architecture, Kubernetes driver, compute-driver reference, and cluster-debugging skill.

Testing

• mise run pre-commit passes
• Focused Rust suite passes for the isolation interface, sandbox backend/runtime, supervisor, supervisor network, and Kubernetes driver (1,272 supervisor-network tests; all selected tests passed)
• Workspace-wide cargo clippy --workspace --all-targets -- -D warnings passes
• Unit tests added for adapter-bound audit evidence, unfiltered workload launch, explicit proxy acceptance, and gVisor Kubernetes provisioning/security context
• mise run ci completes: all relevant code checks passed, but the pre-existing deterministic test:e2e-parity fixture failed because both its baseline and candidate fake wrappers emitted no manifests or reports
• GKE Sandbox end-to-end validation (requires a gVisor-enabled GKE node pool)

Known limitations

• Only proxy-aware HTTP/HTTPS clients are mediated. Direct TCP, UDP, and direct DNS remain blocked by the outer NetworkPolicy.
• Filesystem enforcement is limited to the gVisor sentry plus OCI mounts; Landlock path allowlists are unavailable.
• Process attribution is sandbox/session plus requested endpoint, not executable identity.
• The workload UID model is unchanged in this PR.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-3367.docs.buildwithfern.com/openshell

[mayawang]

The limitations section here is unusually clear and it answers most of what I would have asked.

Reading it alongside #3366 though, there now look like two ways to add an isolation primitive and I want to check which one to build against. This PR adds gVisor as an adapter inside the OpenShell sandbox runtime, reusing OpenShellRuntimeBackend and the sandbox protocol. #3362 assumes the other route, a separate backend behind the RFC 12 interface.

Is the adapter the intended path for new primitives, with the RFC 12 backend aimed at something else? Or are both supported, and is there a line between them?