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/app-server-protocol/src/protocol/v2/permissions.rs

@@ -312,11 +312,13 @@ pub enum FileSystemPath {
 impl From<CoreFileSystemPath> for FileSystemPath {
     fn from(value: CoreFileSystemPath) -> Self {
         match value {
-            CoreFileSystemPath::Path { path } => Self::Path {
+            CoreFileSystemPath::Path { path }
+            | CoreFileSystemPath::GeneratedDefaultPath { path } => Self::Path {
                 path: LegacyAppPathString::from_abs_path(&path),
             },
             CoreFileSystemPath::GlobPattern { pattern } => Self::GlobPattern { pattern },
-            CoreFileSystemPath::Special { value } => Self::Special {
+            CoreFileSystemPath::Special { value }
+            | CoreFileSystemPath::GeneratedDefaultSpecial { value } => Self::Special {
                 value: value.into(),
             },
         }