shell-command: reuse a PowerShell parser process on Windows

[bolinfest]

Why

//codex-rs/shell-command:shell-command-unit-tests became a real bottleneck in the Windows Bazel lane because repeated calls to is_safe_command_windows() were starting a fresh PowerShell parser process for every powershell.exe -Command ... assertion.

PR #16056 was motivated by that same bottleneck, but its test-only shortcut was the wrong layer to optimize because it weakened the end-to-end guarantee that our runtime path really asks PowerShell to parse the command the way we expect.

This PR attacks the actual cost center instead: it keeps the real PowerShell parser in the loop, but turns that parser into a long-lived helper process so both tests and the runtime safe-command path can reuse it across many requests.

What Changed

• add shell-command/src/command_safety/powershell_parser.rs, which keeps one mutex-protected parser process per PowerShell executable path and speaks a simple JSON-over-stdio request/response protocol
• turn shell-command/src/command_safety/powershell_parser.ps1 into a long-running parser server with comments explaining the protocol, the AST-shape restrictions, and why unsupported constructs are rejected conservatively
• keep request ids and a one-time respawn path so a dead or desynchronized cached child fails closed instead of silently returning mixed parser output
• preserve separate parser processes for powershell.exe and pwsh.exe, since they do not accept the same language surface
• avoid a direct PipelineChainAst type reference in the PowerShell script so the parser service still runs under Windows PowerShell 5.1 as well as newer pwsh
• make shell-command/src/command_safety/windows_safe_commands.rs delegate to the new parser utility instead of spawning a fresh PowerShell process for every parse
• add a Windows-only unit test that exercises multiple sequential requests against the same parser process

Testing

• adds a Windows-only parser-reuse unit test in powershell_parser.rs
• the main end-to-end verification for this change is the Windows CI lane, because the new service depends on real powershell.exe / pwsh.exe behavior

[bolinfest]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".