fix(sandboxing): Bound advisory system bwrap startup probe

[viyatb-oai]

Why

Linux startup runs an advisory system bwrap warning probe on each launch. On hosts with NFS or autofs mounts, its --ro-bind / / probe can take tens of seconds before Codex prints anything, matching #19828. Because this probe only decides whether to surface a warning, it should not be allowed to stall startup.

Relevant pre-change path: codex-rs/sandboxing/src/bwrap.rs

What changed

• Bound the advisory system bwrap probe to 500 ms.
• Preserve the existing warning behavior when bwrap promptly reports a known user-namespace failure.
• Kill and reap the probe child on timeout, then suppress the advisory warning instead of blocking startup.
• Read probe stderr with a bounded nonblocking drain so descendants that inherit the pipe cannot extend startup after the probe child exits.
• Add regression coverage for both a deliberately slow fake bwrap process and a fake probe whose descendant keeps stderr open.

Security

This only bounds the advisory startup probe. It does not change the command execution path or add a fail-open sandbox fallback. The related command-side hang in #20017 remains separate from this PR.

Verification

• Added system_bwrap_probe_times_out_without_reporting_a_warning.
• Added system_bwrap_probe_does_not_wait_for_descendants_holding_stderr_open.
• cargo test -p codex-sandboxing
• cargo clippy -p codex-sandboxing --all-targets -- -D warnings

Fixes #19828
Related: #20017

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7db3018aa7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[rreichel3-oai]

Looks good, discussed offline to ensure that this wouldn't cause timeouts for /dev and /proc and other special FS mount points.