Windows: Remove-Item guard blocks any command containing a path with a space

## Summary

On Windows, the built-in `Remove-Item` protection blocks a command whenever the command text contains **any Windows path with a space in it**, regardless of what is actually being deleted. The guard appears to split the path at the first space and treat the leading fragment as a protected drive root.

The error names a fragment, not a real path:

```
Remove-Item on system path '"C:\Program' is blocked. This path is protected from removal.
```

Note `'"C:\Program'` — the leading quote is included and the path is truncated at the space.

## Reproduction

Each of these is a single PowerShell tool call. The file being deleted is always a throwaway file in `%TEMP%`.

**1. Baseline — passes**

```powershell
$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
```

**2. Path without a space — passes**

```powershell
$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
$other = "C:\Python314\python.exe"
```

**3. Path with a space — BLOCKED**

```powershell
$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
& "C:\Program Files\Git\bin\bash.exe" -c "echo hello"
```

→ `Remove-Item on system path '"C:\Program' is blocked.`

**4. Ordinary user directory with a space — BLOCKED**

```powershell
$t = "$env:TEMP\probe.txt"
"x" | Set-Content $t
Remove-Item $t -ErrorAction SilentlyContinue
$other = "C:\AI Projects\README.md"
```

→ `Remove-Item on system path '"C:\AI' is blocked.`

**5. Reversed order — still BLOCKED**

Putting the spaced path *before* `Remove-Item` blocks identically, so this is not proximity or line based.

## Expected vs actual

**Expected:** the guard inspects the argument actually passed to `Remove-Item` and blocks only if *that* resolves to a protected location.

**Actual:** the guard scans the whole command text for two independent things — the verb `Remove-Item`, and anything shaped like a path — and blocks on the pair. The deletion target is never consulted.

## Impact

Case 4 is the important one. `C:\AI Projects` is an ordinary user working directory, not a system path. Any project whose folder name contains a space makes every cleanup command unrunnable, because merely *mentioning* the project path anywhere in the command triggers the guard.

Two very common Windows paths hit this by construction:

- `C:\Program Files\...` → reported as `C:\Program`
- `C:\Users\\My Documents\...` and similar

The practical effect is worse than an inconvenience. Deleting a stale artifact before re-running a check is often what makes the check valid. When that step is blocked, the natural workaround is to drop the cleanup — and the check then silently reuses the old artifact and can no longer fail.

## Environment

- Claude Code, desktop app (Code tab)
- Windows 11 Pro 10.0.22631
- PowerShell 7.6.5
- Model: Opus 4.5

The message string `protected from removal` is present in the bundled `claude.exe` shipped under `claude_agent_sdk/_bundled/`, so this is product behaviour rather than a user hook. Confirmed no user-defined hook produces it: the string does not appear in any hook file in the user or project config.

## Suggested fix

Resolve the argument(s) actually passed to `Remove-Item` and compare *those* against the protected list, rather than pattern-matching path-shaped substrings across the whole command. If a text-level check must be kept as a cheap pre-filter, at minimum it should not truncate at whitespace inside a quoted path, and should not treat a two-segment fragment like `C:\AI` as a drive root.

Reproduce the supplied cases in PowerShell on Windows and inspect the bundled claude_agent_sdk/_bundled/claude.exe, where the protected-from-removal message is present. Trace how the Remove-Item guard parses command text, then verify that unrelated quoted paths with spaces no longer block while protected deletion targets remain blocked.

Written by the indexing model from the issue text.