Remove the Bash(git *) blanket allow and add destructive-git deny rules

[ikuwow]

Issue: #187 (the issue recommended an enumerated allowlist; this PR lands a smaller shape than that recommendation — see Background)

Why

Bash(git *) auto-approved every git subcommand at the rule layer, including the ACE vectors the issue lists (git config core.pager / core.editor / core.sshCommand / core.hooksPath writes, git apply/am against untrusted patches) and any unknown or future subcommand. Rule-layer allow matches skip every downstream safety check, so the blanket entry has to go regardless of permission mode.

What

• Remove Bash(git *) from permissions.allow. Nothing replaces it.
• Add 7 deny entries closing the destructive-push and single-file-discard gaps from the issue: git push --delete / git push * --delete / git push --mirror / git push * --mirror / the colon-prefix branch-delete refspec (git push * :*), plus git checkout -- * / git checkout * -- *.
• The ask list is untouched. Main's existing git claw-backs (git rebase *, git reset *, git clean *, git branch -D *, git config *, etc.) stay and keep forcing prompts.

Background: why no allowlist

This settings file runs with permissions.defaultMode: "auto". Per the official docs (code.claude.com/docs permissions / permission-modes pages, checked 2026-07-27):

• Read-only Bash commands (git status, git log, ...) are auto-approved in every mode, so enumerating them in allow is redundant
• git add (working-directory file writes) and git push to the working repository are auto-approved under auto mode (push since v2.1.211)
• Rule precedence is deny -> ask -> allow independent of mode, and ask rules force a prompt even in auto mode

So under auto mode, deny + ask lists are the two levers that matter; an enumerated read-only allowlist adds 60+ lines of maintenance surface with no behavioral effect. An earlier revision of this branch carried that allowlist; it was dropped in the final commit.

Note: this PR makes destructive git subcommands (reset, clean, rebase, ...) flow to the ask claw-backs or the auto-mode classifier instead of being rule-approved by the blanket allow. Occasional new prompts for unusual git writes are the intended behavior change. If a specific safe command turns out to prompt annoyingly often, add a narrow allow entry for it rather than restoring the blanket.

Verification

• jq . claude/settings.json validates
• git diff main -- claude/settings.json is exactly 1 removed allow line + 7 added deny lines
• No duplicate entries in allow/ask/deny (jq ... | sort | uniq -d empty)
• The deny rules already bite: during the rework, git checkout origin/main -- claude/settings.json was blocked by this branch's own Bash(git checkout * -- *) deny entry (worked around via git show), confirming the pattern matches as intended
• Live behavior after merge + fresh session: git config core.pager <x> and other config writes prompt; git push origin :branch / git checkout -- file are denied; routine status/log/diff/add/push flow without new prompts