Separate executor sandbox selection from Windows sandbox levels (#45730)

## Why

MXC is a sandbox implementation, not a restricted-token sandbox level. Executor requests need to represent that choice separately from `WindowsSandboxLevel`.

## What changed

- Introduce `WindowsSandboxSelection` for executor sandbox contexts and remove `Mxc` from `WindowsSandboxLevel`.
- Preserve the `windowsSandboxLevel` wire field and its serialized values for compatibility.
- Share sandbox selection between executor process launches and filesystem helpers, and use the new selection in capability discovery and skill reads.
- Disable Windows sandbox selection for executor paths that do not use Windows path conventions.

## Testing

Extend coverage for MXC wire serialization, Windows skill-read sandbox checks, and capability discovery with distinct permissions. Exercise remote filesystem write restrictions with both restricted-token and MXC sandboxes, including rejection when native MXC is unavailable.

GitOrigin-RevId: 266211377bcb138a0dc75861e9ff2225fa37a53d

codex-rs/exec-server/src/capability_discovery.rs

@@ -78,9 +78,7 @@ async fn discover_root(
 
     #[cfg(target_os = "windows")]
     if sandbox.is_some_and(|context| {
-        context.should_run_in_sandbox()
-            && context.windows_sandbox_level
-                == codex_protocol::config_types::WindowsSandboxLevel::Disabled
+        context.should_run_in_sandbox() && !context.windows_sandbox_is_requested()
     }) {
         discovery.error = Some("filesystem sandbox is unavailable on this executor".to_string());
         return discovery;