Add PreToolUse:Bash guard so a repo-scoped push-without-ask override cannot apply to a different repository

[DrumRobot]

Problem

Some project workflows define a narrow, repository-scoped override that allows an autonomous agent to git push a feature branch without asking for confirmation first, as long as the push targets one specific, named repository (a documented exception to the general "always ask before pushing" default). The override's scope is stated in prose in the workflow's own documentation, but nothing enforces it at the moment a push command is actually issued.

This creates a real risk: when the same agent later performs a similar workflow (commit → create a worktree → push → open a draft PR) against a different repository, the override can be unconsciously carried over and applied there too, even though it was never meant to extend beyond the one named repository. This has already happened at least once — a push to a different repository went out without the expected confirmation step, because the narrow override was applied outside its intended scope. In that occurrence the impact was low (a brand-new branch with no PR opened yet, so it was easy to correct after the fact), but the same mistake against a shared/protected branch or an already-open PR could be much harder to undo.

Scope

1. Add a PreToolUse:Bash guard hook (in skills/hook-kit/resources/) that fires on git push invocations.
2. On match, the hook should determine the target remote/repository for the push (e.g. by resolving the git remote URL of the current working directory, or by inspecting the command's explicit remote argument) and compare it against the specific repository the no-ask override is scoped to.
3. If the target repository does not match the override's designated repository, the hook should enforce the general "ask before pushing" default (i.e. treat the override as inapplicable) rather than silently allowing the push through.
4. If the target repository does match, the hook should allow the push to proceed without additional confirmation, preserving the intended fast-path for that one repository.
5. Add a fixture/self-test covering: (a) a push whose target repo matches the override's designated repo → allowed without extra confirmation, (b) a push whose target repo does not match → the general ask-before-push behavior applies instead.

Verification

Feature	Procedure	Expected Result
Override applies to its designated repo	Simulate a PreToolUse:Bash payload for git push origin <branch> run from a working directory whose remote matches the override's designated repository	Hook allows the push without requiring extra confirmation
Override does not leak to other repos	Simulate the same push command run from a working directory whose remote points to a different repository	Hook does not silently allow it — the general ask-before-push behavior is enforced
No false positive on non-push commands	Simulate a non-push git command (e.g. git status, git fetch)	Hook does not fire
Existing hook fixtures	Run the hook-kit self-test suite	All existing tests still pass