Plan mode over-blocks read-only shell commands (keyword false positives)

### Describe the bug

In plan mode, the  powershell /shell tool is gated by a heuristic that blocks commands which "may modify the workspace." The classifier appears to match on substrings/tokens rather than actual command semantics, so several provably read-only commands are wrongly blocked, making repository investigation in plan mode harder than it should be.

Confirmed false positives (all read-only, all blocked):

•  git merge-base origin/master HEAD  — blocked because the string contains  merge  (matches the mutating verb  git merge , but  merge-base  only reads).
•  $mb = git rev-parse HEAD  and similar — blocked because of the  =  assignment (looks like state change; it isn't).
•  Select-String  /  Get-Content  — blocked though they only read.

Commands that correctly pass (for contrast):

•  git branch --show-current ,  git status ,  git --no-pager log/diff/show ,  git grep , and  cd …; git branch …  chains.

Impact: Plan mode is meant for read-only investigation (e.g. code review), yet common read-only git/PowerShell reads get blocked, forcing awkward rephrasing.

Suggested fixes:

1. Match git verbs as whole tokens ( ^git\s+merge\b ), not the  merge  substring — unblocks  merge-base ,  merge-tree --write-pack  excluded, etc.
2. Treat variable assignment of a read-only command as read-only (or ignore  =  alone as a mutation signal).
3. Allow-list known read-only cmdlets:  Select-String ,  Get-Content ,  Get-ChildItem ,  Get-Item ,  Test-Path .
4. Optionally: a plan-mode setting to permit an explicit read-only shell allow-list.

### Affected version

1.0.71

### Steps to reproduce the behavior

Enter plan mode → run  git merge-base origin/master HEAD  → observe it's blocked as "may modify the workspace."

### Expected behavior

In plan mode, commands that are provably read-only should be permitted; only commands that can actually mutate the workspace, git state, or files should be blocked. Specifically:

•  git merge-base origin/master HEAD  should run — it only computes a commit SHA and writes nothing. Read-only git subcommands ( merge-base ,  log ,  diff ,  show ,  status ,  rev-parse ,  branch --show-current ,  grep ) should all be allowed, regardless of substrings in their names.
•  $mb = git rev-parse HEAD  should run — assigning a read-only command's output to a shell variable does not modify the workspace; the mutation check should evaluate the underlying command, not the presence of  = .
•  Select-String ,  Get-Content ,  Get-ChildItem ,  Test-Path  should run — they only read.
• Classification should be based on command semantics / whole-token verb matching, not substring matching, so  merge-base  is not conflated with  git merge .

Actual behavior:
All of the above are blocked with "This shell command may modify the workspace and was blocked. Plan mode does not permit changes to the workspace," even though none of them write anything — forcing the read-only investigation that plan mode is designed for to be rephrased or abandoned.

### Additional context

_No response_

Start at the plan-mode powershell/shell tool command classifier described in the issue, reproducing the listed false positives with git merge-base, variable assignment, and read-only cmdlets. Trace how command tokens are classified and verify that read-only commands are allowed while commands that can mutate the workspace remain blocked.

Written by the indexing model from the issue text.