DESTRUCTIVE (forced) git branch deletion is MISCLASSIFIED and requires NO PERMISSION

### Describe the bug

Per `/diagnose`:

---

Found it. The root cause is clear from the event log:

- **`git push --delete`** at 20:42:24 → generated a `permission.request` event → you were prompted ✅
- **`git branch -D`** at 20:43:03 → **no `permission.request` event at all** → ran silently ❌

The CLI classifies commands by identifier to determine if they're read-only. In the `git push` permission request, `git push` is correctly tagged `"readOnly": false`. But earlier in the session, `git branch -r` was tagged `"readOnly": true` — and the classifier appears to treat **all `git branch` invocations as read-only**, regardless of flags like `-D`.

In short: **this is a classifier bug in the CLI**. It doesn't recognize that `git branch -D` is destructive, so it skips the permission prompt entirely. `git push --delete` was correctly flagged; `git branch -D` was not.

This is worth reporting via `/feedback` — the `git branch` command classifier needs to recognize `-D` / `-d` / `--delete` as write operations.

### Affected version

GitHub Copilot CLI 1.0.71.

### Steps to reproduce the behavior

- Ask Copilot to delete one or more remote branches to provoke it to call `git push --delete ...`.
- Observe that the command requires user acknowledgement.
- Ask Copilot to delete one or more local branches to provoke it to call `git branch -D ...`.
- Observe that the command runs with no permission prompt.

### Expected behavior

A destructive operation such as DELETING A BRANCH should require confirmation by default.

### Additional context

_No response_

Start at the CLI command classifier and inspect how git branch identifiers are mapped to readOnly and permission.request events. Reproduce with git branch -D, -d, and --delete, then verify destructive variants require confirmation while git branch -r remains read-only.

Written by the indexing model from the issue text.