fix(supervisor): preserve standard sbin paths in sandbox shells

[elezar]

Summary

Preserve standard sbin directories in supervisor-launched sandbox child shells when CDI exposes tools such as /usr/sbin/nvidia-smi on Orin systems.

Related Issue

No issue required: small localized regression fix discovered while validating stacked PR #2265 on an Orin Docker GPU gateway.

Changes

• Added supervisor child PATH normalization helpers for /usr/local/sbin, /usr/sbin, and /sbin.
• Gated the standard-sbin PATH repair on both the expected CDI context and an effective policy path under a standard sbin directory, such as /usr/sbin/nvidia-smi.
• Installed the idempotent profile.d/.bashrc repair only when the CDI/policy gate is active.
• Hardened startup-file repair so it skips symlinks, parent-directory symlinks, and non-regular startup files instead of following image-controlled paths as root.
• Wrapped supervisor-launched shell -c entrypoints and SSH exec/login-shell commands only when the CDI/policy gate is active.
• Normalized provider-supplied PATH values on both entrypoint and SSH execution paths only when the CDI/policy gate is active.
• Added focused unit tests for gate behavior, PATH normalization, startup snippet idempotency, startup symlink handling, entrypoint shell wrapping, provider PATH handling, and SSH child env handling.

Testing

• mise x -- cargo test -p openshell-supervisor-process standard_sbin
• mise x -- cargo test -p openshell-supervisor-process startup_snippet
• mise x -- cargo test -p openshell-supervisor-process symlink
• mise x -- cargo test -p openshell-supervisor-process inject_provider_env
• mise x -- cargo test -p openshell-supervisor-process apply_child_env
• mise x -- cargo clippy -p openshell-supervisor-process --all-targets -- -D warnings
• Static arm64 supervisor rebuild via PREBUILT_ARCH=arm64 bash tasks/scripts/stage-prebuilt-binaries.sh supervisor-output
• GPU sandbox probe on Orin against local dev gateway: PATH includes /usr/sbin, command -v nvidia-smi resolves /usr/sbin/nvidia-smi, and nvidia-smi -L reports the Orin GPU
• Non-GPU sandbox probe against the same gateway: PATH=/sandbox/.venv/bin:/usr/local/bin:/usr/bin:/bin, confirming the CDI gate leaves ordinary sandboxes untouched
• Docker GPU e2e on Orin against local dev gateway before the CDI gate: 10 passed / 0 failed
• mise run pre-commit passes
  • Attempted again on 2026-08-21; blocked by existing local setup issues: Helm lint reports chart metadata missing postgresql, and workspace Rust lint hits a stale sqlx_macros artifact requiring GLIBC_2.39.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)

[github-actions]

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

[sandl99]

AGX Thor validation update

We reproduced the Jetson CUDA failure and passed the NemoClaw onboarding GPU gate on an NVIDIA AGX Thor through OpenShell's native Docker CDI route.

✓ GPU proof passed: nvidia-smi when available
✓ GPU proof passed: /proc/<pid>/task/<tid>/comm write
✓ GPU proof passed: cuInit(0) via libcuda.so.1
✓ Sandbox CUDA usability proven (cuInit succeeded).

The isolation result was:

host                                      cuInit(0)=0
plain Docker CDI                          cuInit(0)=0
same container and non-root UID/GIDs      cuInit(0)=0
OpenShell supervisor without /sys access  cuInit(0)=801
OpenShell supervisor with /sys read-only  cuInit(0)=0

This confirms that #2846 fixes the Jetson PATH issue: /usr/sbin/nvidia-smi was found and passed. It also shows two separate gaps outside this PR's current scope:

1. Thor CUDA initialization requires sysfs access that is not present in the CDI-enriched Landlock policy. We used a test-only read-only /sys grant. A production fix should define the minimum safe sysfs contract or explicitly approve the broader read-only grant.
2. The Thor CDI enrichment generated 301 filesystem paths, which exceeded the current 256-path policy limit. We used a local 512-path limit for this test.

The tested binary was based on OpenShell 1e5116ca8 plus the local path-limit change, not the current #2846 commit e2c6cc7d29df69ca5cefad107cd989de605127ec. The result should therefore be repeated on the final upstream stack after the sysfs and policy-capacity gaps are resolved. This comment records GPU-stage evidence only; it does not claim that full NemoClaw onboarding exited successfully.

The sysfs and path-capacity work appears best tracked under #1606 or a focused child issue, while #2846 remains the PATH fix.