PowerShell tool spawns a bare, visible powershell.exe host window (Windows)

## Environment
- OS: Windows 11 Home 10.0.26200
- Claude Code (desktop app): 2.1.271
- Shell config: PowerShell tool as primary, Bash tool also available

## Summary

Invoking the built-in **PowerShell tool** spawns a bare `powershell.exe` (no arguments, no `-WindowStyle Hidden`, no console suppression) as its backing shell process. Since the Claude Code desktop app is a GUI process with no console of its own, Windows must give this child a console — and because Windows Terminal is the default terminal application, it gets hosted in a fully visible `WindowsTerminal.exe` window titled "Windows PowerShell". This steals focus and interrupts whatever the user is doing in another window.

This happens **before any PreToolUse hook even runs** — I confirmed it fires even when a PreToolUse hook denies the tool call outright, so it's the tool's own process startup, not anything scriptable/hookable from user config.

## Impact

Every session's first use of the PowerShell tool (and possibly every use — see below) produces one visible, focus-stealing window flash. On a workstation running several concurrent Claude Code sessions, this presents as frequent, seemingly random console flashes throughout the day, which is difficult for users to diagnose because:

- It is not caused by any `hooks` entry in `settings.json`.
- It is not caused by any MCP server registration.
- It is not caused by any scheduled task.
- `-WindowStyle Hidden` is not applicable since the user has no control over this spawn at all.

## Repro

1. On Windows, with Windows Terminal set as the default terminal application (the Windows 11 default).
2. In a Claude Code session, invoke the PowerShell tool with any command.
3. Observe a `WindowsTerminal.exe` window titled "Windows PowerShell" become visible momentarily.

## Diagnosis method

Verified with a live `EnumWindows` watcher (via a short ctypes script) polling for visible windows of class `ConsoleWindowClass` / `CASCADIA_HOSTING_WINDOW_CLASS` while exercising both tools in the same session:

- Multiple **Bash** tool calls: zero visible console-class windows observed.
- One **PowerShell** tool call: one visible `CASCADIA_HOSTING_WINDOW_CLASS` window appeared, titled "Windows PowerShell", traced via `Get-CimInstance Win32_Process` back to a bare `powershell.exe` process with an empty command line, itself parented by a COM-activated `WindowsTerminal.exe -Embedding` process (i.e., DCOM launch of the default terminal host) — not by any hook, MCP server, or scheduled task on the machine.

## Suggested fix

Spawn the PowerShell tool's backing process with `CREATE_NO_WINDOW` (and ideally via a `pythonw`/GUI-subsystem-style detached launch, or `STARTUPINFO.dwFlags = STARTF_USESHOWWINDOW` + `wShowWindow = SW_HIDE` combined with `CREATE_NO_WINDOW`), the same way a well-behaved hook launcher must, so it never allocates a visible console/terminal window regardless of the user's default terminal application setting.

## Workaround

Users can avoid the flash entirely by preferring the Bash tool over the PowerShell tool whenever the command doesn't require PowerShell-specific cmdlets.

Start at the PowerShell tool's backing-process launch path and reproduce the issue on Windows 11 with Windows Terminal as the default terminal. Verify that the process starts without a visible console or focus-stealing terminal window, while PowerShell commands still execute normally; compare behavior with the Bash tool and test a denied tool call if relevant.

Written by the indexing model from the issue text.