fix: support split carveouts in windows elevated sandbox (#14568)

## Summary
- preserve legacy Windows elevated sandbox behavior for existing
policies
- add elevated-only support for split filesystem policies that can be
represented as readable-root overrides, writable-root overrides, and
extra deny-write carveouts
- resolve those elevated filesystem overrides during sandbox transform
and thread them through setup and policy refresh
- keep failing closed for explicit unreadable (`none`) carveouts and
reopened writable descendants under read-only carveouts
- for explicit read-only-under-writable-root carveouts, materialize
missing carveout directories during elevated setup before applying the
deny-write ACL
- document the elevated vs restricted-token support split in the core
README

## Example
Given a split filesystem policy like:

```toml
":root" = "read"
":cwd" = "write"
"./docs" = "read"
"C:/scratch" = "write"
```

the elevated backend now provisions the readable-root overrides,
writable-root overrides, and extra deny-write carveouts during setup and
refresh instead of collapsing back to the legacy workspace-only shape.

If a read-only carveout under a writable root is missing at setup time,
elevated setup creates that carveout as an empty directory before
applying its deny-write ACE; otherwise the sandboxed command could
create it later and bypass the carveout. This is only for explicit
policy carveouts. Best-effort workspace protections like `.codex/` and
`.agents/` still skip missing directories.

A policy like:

```toml
"/workspace" = "write"
"/workspace/docs" = "read"
"/workspace/docs/tmp" = "write"
```

still fails closed, because the elevated backend does not reopen
writable descendants under read-only carveouts yet.

---------

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

codex-rs/core/README.md

@@ -59,6 +59,12 @@ backend-managed system read roots required for basic execution, such as
 `C:\Windows`, `C:\Program Files`, `C:\Program Files (x86)`, and
 `C:\ProgramData`. When it is `false`, those extra system roots are omitted.
 
+The elevated Windows sandbox also supports:
+
+- legacy `ReadOnly` and `WorkspaceWrite` behavior
+- split filesystem policies that need exact readable roots, exact writable
+  roots, or extra read-only carveouts under writable roots
+
 The unelevated restricted-token backend still supports the legacy full-read
 Windows model for legacy `ReadOnly` and `WorkspaceWrite` behavior. It also
 supports a narrow split-filesystem subset: full-read split policies whose
@@ -66,12 +72,11 @@ writable roots still match the legacy `WorkspaceWrite` root set, but add extra
 read-only carveouts under those writable roots.
 
 New `[permissions]` / split filesystem policies remain supported on Windows
-only when they round-trip through the legacy `SandboxPolicy` model without
-changing semantics. Policies that would require direct read restriction,
-explicit unreadable carveouts, reopened writable descendants under read-only
-carveouts, different writable root sets, or split carveout support in the
-elevated setup/runner backend still fail closed instead of running with weaker
-enforcement.
+only when they can be enforced directly by the selected Windows backend or
+round-trip through the legacy `SandboxPolicy` model without changing semantics.
+Policies that would require direct explicit unreadable carveouts (`none`) or
+reopened writable descendants under read-only carveouts still fail closed
+instead of running with weaker enforcement.
 
 ### All Platforms