[codex] Trust only system PowerShell parsers on Windows

[bookholt-oai]

Why

On Windows, PowerShell safety classification recognized argv[0] by basename and then launched that same model-selected path as a host-side AST parser. A repository-controlled pwsh.exe or powershell.exe could therefore execute before the approval and sandbox boundaries and could forge a parser response.

What

• Fail closed unless the command names an exact trusted default Windows PowerShell or PowerShell 7 installation path.
• Spawn the parser from a fixed trusted path instead of passing command-controlled argv[0] to Command::new.
• Keep powershell.exe and pwsh.exe parser semantics separate while rejecting bare names, relative paths, workspace paths, command wrappers, and missing installs.
• Preserve the existing PowerShell AST-region rejection from [codex] Reject unlowered PowerShell AST regions #24092 and the non-Windows guard from [codex] Avoid PowerShell safety parsing off Windows #24946.

How

The shared PowerShell parser entry point now resolves the command executable against two fixed, protected Windows installation paths and verifies the selected binary exists. The lower-level process launcher is private, so both Windows safe-command classification and exec-policy unwrapping must pass through the trust check. Tests cover case and separator normalization, extended-length trusted paths, CWD/PATH ambiguity, absolute workspace paths, .cmd wrappers, path aliases, missing installs, and both PowerShell variants. A Windows-only interface regression copies a real PowerShell binary to workspace-controlled powershell.exe and pwsh.exe paths and verifies neither is classified as safe.

Testing

• just fmt
• just test -p codex-shell-command — 142 passed
• just fix -p codex-shell-command
• git diff --check

Windows-only runtime coverage will run in CI; the path-resolution variants run on every platform.

Linear

• PSEC-4922
• BUGB-17232