fix(sandbox): restore GPU procfs baseline

[elezar]

Summary

Restore CUDA GPU startup compatibility by promoting /proc from
filesystem_policy.read_only to filesystem_policy.read_write when /proc
is part of the active GPU runtime baseline.

This keeps the change intentionally narrow. The existing baseline enrichment
already places /proc in the GPU read-write baseline because CUDA writes
/proc/<pid>/task/<tid>/comm during initialization. The missing behavior was
that an existing read-only /proc entry caused enrichment to skip the
read-write baseline path. This PR restores that promotion and emits an
informational log message when it happens.

Broader handling for user-supplied policy conflicts and explicit baseline
conflict controls is left to follow-up work such as #1629.

Related Issue

Fixes #1486

Related follow-up: #1629

Changes

• Promote /proc from read_only to read_write when the GPU read-write
  baseline requires it.
• Preserve existing behavior for other read-only/read-write baseline conflicts.
• Emit an informational log when /proc is promoted for GPU runtime
  compatibility.
• Add a regression test covering GPU baseline enrichment without network
  policy.

Testing

• mise exec -- cargo fmt --all
• mise exec -- cargo test -p openshell-sandbox --lib baseline_tests -- --nocapture
• mise run pre-commit completed Helm lint, Rust format, Rust check, Rust clippy, markdown lint, and license checks; python:proto failed in the parallel run because grpc_tools was missing after .venv recreation.
• mise run python:proto

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture/docs updated (not applicable for this minimal runtime fix)

[github-actions]

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

[pimlock]

LGTM with a few nits and questions.

[elezar]

Thanks for your initial review @pimlock. After the initial back and forth, I realised that there were a number of edge cases that I was not considering. I believe I was trying to detect user intent with insufficient signal and as such have updated this PR to ALWAYS promote /proc to read-write if GPUs are requested and instead capture explicit intent in #1629 as a follow-up. This PR would unblock the GPU-enabled tests, but I'm happy to continue iterating on it if required.

[pimlock]

Thanks for your initial review @pimlock. After the initial back and forth, I realised that there were a number of edge cases that I was not considering. I believe I was trying to detect user intent with insufficient signal and as such have updated this PR to ALWAYS promote /proc to read-write if GPUs are requested and instead capture explicit intent in #1629 as a follow-up. This PR would unblock the GPU-enabled tests, but I'm happy to continue iterating on it if required.

Thanks! I took a first pass at #1629 and I like the approach. I think it's great for the mechanism to be more explicit and exposing it through the policy makes sense, so the full picture of what's allowed is in the policy.