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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.