Avoid creating metadata paths in the Windows sandbox (#33430)

## Why

Elevated Windows sandbox setup could turn the built-in read-only protections
for workspace metadata into deny-write paths, creating metadata directories
that did not already exist.

## What changed

- Track whether filesystem permission entries come from a built-in profile or
  were explicitly configured.
- Exclude generated metadata defaults from direct Windows deny-write overrides
  while continuing to enforce explicit read-only carveouts for the same paths.
- Preserve the distinction while materializing and normalizing permission
  paths, without exposing generated defaults as user configuration.

## Testing

Added Windows coverage confirming that elevated sandbox setup leaves missing
workspace metadata absent and still produces overrides for explicit metadata
carveouts.

GitOrigin-RevId: 701bcb229f631b18ab5ced22f3edf6f303d932f3

codex-rs/core/src/config/config_tests.rs

@@ -4263,7 +4263,7 @@ exclude_slash_tmp = true
                         file_system_policy
                             .entries
                             .contains(&FileSystemSandboxEntry {
-                                path: FileSystemPath::Path {
+                                path: FileSystemPath::GeneratedDefaultPath {
                                     path: AbsolutePathBuf::resolve_path_against_base(
                                         subpath,
                                         cwd.path()

codex-rs/core/src/config/permissions.rs

@@ -249,6 +249,8 @@ fn insert_filesystem_permission_toml(
         FileSystemPath::Special { value } => {
             insert_special_filesystem_permission_toml(entries, value, entry.access);
         }
+        FileSystemPath::GeneratedDefaultPath { .. }
+        | FileSystemPath::GeneratedDefaultSpecial { .. } => {}
     }
 }