Add opt-in raw-git nudge hook, independent of anti-chaining hook

Forces a normal confirmation prompt (never a silent block, never a silent
allow) when Bash runs raw git instead of git_cmd.sh, worded more
insistently when the subcommand is one the wrapper already supports.
Raw git stays a valid fallback for unsupported subcommands and
unregistered repos - a hard deny would remove that fallback entirely.

Also documents in SKILL.md that repo ambiguity (which registered repo is
meant, or none at all) must be resolved by asking the user rather than
guessing - a hook only sees the literal command string, not the
conversation, so that judgment can't live in the hook itself.

skills/git-manager/SKILL.md

@@ -78,6 +78,20 @@ purpose as a guardrail, not an oversight. Those excluded subcommands can
 rewrite or discard history/working-tree state in ways that are hard to
 reverse; `tag` is allowed because tagging a commit doesn't carry that risk.
 
+## When it's unclear which repo is meant
+
+Don't guess. If a task says "the repo" or otherwise implies a repo without
+naming one, and it's genuinely ambiguous which registered repo (if any) it
+refers to, or the request's context doesn't clearly match any registered
+repo at all, ask the user before picking a `--repo` or falling back to raw
+git. Concretely, this is already handled operationally rather than needing
+new logic: call `git_cmd.sh` without `--repo` and let it resolve —
+`resolve_repo_path` in `_lib.sh` errors out listing every registered name
+when more than one repo is configured and none was specified, and errors
+saying none are registered when the config is empty. Either error is the
+signal to ask the user which repo (or whether to register a new one),
+rather than picking one, or reaching for raw git, on your own.
+
 ## Multi-repo setup
 
 If a task refers to a named repo (e.g. "push the homelab-notes vault") and