Protect managed MITM CA private keys from sandboxed commands

[winston-openai]

Why

#22668 made the managed MITM trust bundle readable to sandboxed commands, but the sibling CA private key remains under the same-user-readable $CODEX_HOME/proxy directory. File mode 0600 does not protect that key from a sandboxed process running as the same user.

What

• add an exact read deny for the managed MITM CA private key to each Codex-managed sandbox policy
• keep the public trust bundle readable when MITM is active
• preserve danger-full-access semantics as root read/write access with only the key carved out
• apply the same policy to normal and debug-sandbox launches
• derive the key path independently of live MITM state so config reloads cannot temporarily expose a persisted key
• route permission profiles requiring exact runtime enforcement through bubblewrap instead of the incompatible legacy Landlock backend

This changes no codex-core files. External sandboxes remain responsible for their own filesystem isolation.

The independent startup custom-CA follow-up is #29014.

Validation

• just test -p codex-network-proxy
• just test -p codex-sandboxing
• just test -p codex-cli debug_sandbox
• just fix -p codex-network-proxy -p codex-sandboxing -p codex-cli

[viyatb-oai]

One compatibility question on the sandbox boundary.