feat(windows-sandbox): add network proxy support (#12220)

## Summary

This PR makes Windows sandbox proxying enforceable by routing proxy-only
runs through the existing `offline` sandbox user and reserving direct
network access for the existing `online` sandbox user.

In brief:

- if a Windows sandbox run should be proxy-enforced, we run it as the
`offline` user
- the `offline` user gets firewall rules that block direct outbound
traffic and only permit the configured localhost proxy path
- if a Windows sandbox run should have true direct network access, we
run it as the `online` user
- no new sandbox identity is introduced

This brings Windows in line with the intended model: proxy use is not
just env-based, it is backed by OS-level egress controls. Windows
already has two sandbox identities:

- `offline`: intended to have no direct network egress
- `online`: intended to have full network access

This PR makes proxy-enforced runs use that model directly.

### Proxy-enforced runs

When proxy enforcement is active:

- the run is assigned to the `offline` identity
- setup extracts the loopback proxy ports from the sandbox env
- Windows setup programs firewall rules for the `offline` user that:
  - block all non-loopback outbound traffic
  - block loopback UDP
  - block loopback TCP except for the configured proxy ports
- optionally allow broader localhost access when `allow_local_binding=1`

So the sandboxed process can only talk to the local proxy. It cannot
open direct outbound sockets or do local UDP-based DNS on its own.The
proxy then performs the real outbound network access outside that
restricted sandbox identity.

### Direct-network runs

When proxy enforcement is not active and full network access is allowed:

- the run is assigned to the `online` identity
- no proxy-only firewall restrictions are applied
- the process gets normal direct network access

### Unelevated vs elevated

The restricted-token / unelevated path cannot enforce per-identity
firewall policy by itself.

So for Windows proxy-enforced runs, we transparently use the logon-user
sandbox path under the hood, even if the caller started from the
unelevated mode. That keeps enforcement real instead of best-effort.

---------

Co-authored-by: Codex <noreply@openai.com>

codex-rs/cli/src/debug_sandbox.rs

@@ -164,14 +164,17 @@ async fn run_command_under_sandbox(
             let res = tokio::task::spawn_blocking(move || {
                 if use_elevated {
                     run_windows_sandbox_capture_elevated(
-                        policy_str.as_str(),
-                        &sandbox_cwd,
-                        base_dir.as_path(),
-                        command_vec,
-                        &cwd_clone,
-                        env_map,
-                        /*timeout_ms*/ None,
-                        config.permissions.windows_sandbox_private_desktop,
+                        codex_windows_sandbox::ElevatedSandboxCaptureRequest {
+                            policy_json_or_preset: policy_str.as_str(),
+                            sandbox_policy_cwd: &sandbox_cwd,
+                            codex_home: base_dir.as_path(),
+                            command: command_vec,
+                            cwd: &cwd_clone,
+                            env_map,
+                            timeout_ms: None,
+                            use_private_desktop: config.permissions.windows_sandbox_private_desktop,
+                            proxy_enforced: false,
+                        },
                     )
                 } else {
                     run_windows_sandbox_capture(