`--allow-tool shell(git)` does not blanket-allow all git subcommands — only a narrow undocumented subset is covered

### Describe the bug

When launching Copilot CLI with `--allow-tool shell(git)`, the expectation is that all `git` commands can be executed without triggering a user permission prompt. In practice, only a small, undocumented subset of git subcommands is silently allowed; the vast majority still require explicit user confirmation.

Most notably, **completely non-destructive, read-only informational commands** such as `git --version` and `git help` still prompt for permission — even though they carry zero risk of modifying any state. This makes the current behavior both surprising and inconsistent with user expectations.

Additionally, `--deny-tool shell(git push)` works correctly as an absolute block.

### Affected version

v0.0.420

### Steps to reproduce the behavior

Launch Copilot CLI with:
```
--allow-tool shell(git) --deny-tool shell(git push)
```

Then ask Copilot to run various `git` subcommands one by one, The prompt I used:
```
I’m testing Copilot’s tool-permission configuration. Copilot is currently launched with the parameters `--allow-tool shell(git)` and `--deny-tool shell(git push)`. Please try running, one by one, all possible Git commands and their subcommands (e.g., `git --version`, `git status`, etc.; you don’t need to care whether the commands error out). Whenever you need me to grant permission, I will refuse and reply with `1`. After you’re done, please compile a list of all commands that can be allowed without requesting permission again, and all commands that still require requesting permission again.
```

## Observed Behavior

### Allowed without permission prompt (subset covered by `shell(git)`):
`git status`, `git log`, `git diff`, `git show`, `git describe`, `git blame`, `git grep`, `git tag`, `git branch` (listing variants), **`git remote` (and all its subcommands)**, `git ls-files`, `git ls-remote`, `git rev-parse`, `git shortlog`

### Still require user permission (NOT covered by `shell(git)`):

**Non-destructive / read-only commands that unexpectedly require permission:**
- `git --version` — reports the installed git version; **cannot modify anything**
- `git help` — displays built-in documentation; **cannot modify anything**

**Other commands requiring permission:**
`git init`, `git add`, `git commit`, `git pull`, `git fetch`, `git clone`, `git checkout`, `git switch`, `git restore`, `git merge`, `git rebase`, `git reset`, `git revert`, `git cherry-pick`, `git stash` (and all subcommands), `git config`, `git bisect`, `git apply`, `git format-patch`, `git am`, `git archive`, `git bundle`, `git cat-file`, `git check-attr`, `git check-ignore`, `git cherry`, `git clean`, `git gc`, `git fsck`, `git ls-tree`, `git mv`, `git rm`, `git notes`, `git reflog`, `git rev-list`, `git show-branch`, `git show-ref`, `git submodule`, `git subtree`, `git worktree`, `git update-index`, `git update-ref`, `git var`, `git verify-commit`, `git verify-tag`, `git whatchanged`, `git count-objects`, `git sparse-checkout`, `git maintenance`, `git range-diff`, `git patch-id`, `git send-email`, `git request-pull`

### Blocked by deny rule (correct behavior):
`git push` — correctly blocked by `--deny-tool shell(git push)` without prompting.

### Expected behavior

`--allow-tool shell(git)` should allow **all** `git` subcommands without prompting (subject to any more-specific `--deny-tool` overrides). At a minimum, the following should be allowed without any prompt:

- **`git --version`** — a completely safe, side-effect-free command that only prints version info
- **`git help`** — a completely safe, side-effect-free command that only displays documentation

The current behavior is inconsistent: `git remote add` (a write operation that modifies `.git/config`) is silently allowed, while `git --version` (which cannot possibly modify anything) requires permission.

### Additional context

- The allowed set corresponds loosely to "repository inspection" commands, but with no clear rule: `git remote add` (write) is allowed, while `git --version` (read) is not.
- There is no documentation describing which subcommands are covered by `shell(git)` vs. requiring explicit `shell(git )` tokens.

The full output of the conversation with Copilot is included in the attachment below:
[Testing git tool permissions.txt](https://github.com/user-attachments/files/25620666/Testing.git.tool.permissions.txt)