Keep managed MITM CA private keys in proxy memory

[winston-openai]

Why

The managed MITM trust bundle must be readable by sandboxed commands. Persisting its sibling CA private key under $CODEX_HOME/proxy therefore requires a deny-read sandbox rule, but the Windows unelevated backend rejects deny-read paths and WSL1's legacy Landlock path cannot enforce that rule.

A persistent OS credential store also does not provide the same cross-platform boundary from other processes running as the same user. Keeping the signer inside the network proxy process avoids both problems: ordinary sandbox setup stays independent of CA-key state, and no private signing key is exposed through the filesystem or a persistent credential record.

What

• generate one managed CA per proxy process and retain its private signer only in proxy memory
• emit only content-addressed public CA certificates and trust bundles under $CODEX_HOME/proxy
• hold a cross-process lease for each active public certificate and prune artifacts from inactive proxy processes
• keep all CA ownership in codex-network-proxy; no codex-core or sandbox-policy changes
• validate generated trust-bundle paths by their content hash
• keep the public bundle readable by sandboxed commands on Windows, WSL1, macOS, and Linux

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

Validation

• CODEX_HOME=/private/tmp/codex-test-home-network-proxy just test -p codex-network-proxy (179 tests)
• just bazel-lock-check
• just fix -p codex-network-proxy
• just fmt

[viyatb-oai]

One compatibility question on the sandbox boundary.