Hardening: Codex write seats can reach the web via backend tools.web__run even with network_access=false

## Summary
For a Codex-provider write seat (`approval_policy = never`), Codex's built-in `tools.web__run` is executed by the backend, so it is not covered by `[sandbox_workspace_write].network_access = false` (which does stop shell network — `curl` fails to resolve). Verified 2026-08-27 by live probe: the seat fetched a page and wrote its content to a file in the working tree.

- Removing MCP web servers from the profile does not close it (the tool is built in).
- `-c tools.web_search=false -c tools.web=false` was silently accepted and had no effect (Codex does not validate unknown config keys).

Why it matters for CAO: an orchestrated write seat that reads untrusted web content can carry prompt-injected instructions straight into a working tree with no human in the loop. `use_worktree=true` mitigates (writes land in a throwaway worktree behind review), and providers with a real `TOOL_MAPPING` can deny the tool.

## Request
1. Document that `network_access=false` does not cover Codex's backend web tool, so operators do not rely on it as a containment control.
2. Consider defaulting write workstreams to `use_worktree=true` for the Codex provider, or warning at profile-load time when a Codex write profile has `network_access=false` but no worktree isolation (the current "cannot enforce tool restrictions (soft/prompt-level only)" warning is close — extending it to name the web tool would be enough).

Filed as a hardening/documentation request; the underlying behavior is Codex's, but CAO is where the containment expectation is set.