Write a PreToolUse hook that blocks a dangerous command before Claude Code runs it

Write a Claude Code PreToolUse hook that mechanically blocks a force-push to any protected branch before it executes, rather than relying on a CLAUDE.md instruction the agent could still talk itself past under pressure to finish a task.

WHAT MUST NEVER RUN
git push --force or git push -f targeting main, master, or any release/* branch, from any working directory in this repo.

WHAT SHOULD STILL BE ALLOWED
A force-push to a personal feature branch under feature/ must still work normally.

PRODUCE
1. The settings.json fragment: a hooks entry under PreToolUse with a matcher narrow enough to catch Bash tool calls whose command string contains push and either --force or -f without also catching unrelated tool calls that happen to share a substring — a matcher that is too broad blocks legitimate work, and one that is too narrow lets a slightly different phrasing of the same dangerous command through.
2. The hook script itself, as a small shell or Python script, that reads the JSON payload from stdin, inspects the tool name and the actual tool input for the dangerous pattern rather than trusting the matcher alone to have caught it precisely, and exits with the code that blocks the call, writing a short, specific reason to stderr — the reason a human, or the agent reading it back, would actually need to understand why this was stopped and what to do instead.
3. A note on exit-code semantics used: which exit code blocks the call and surfaces stderr back to Claude as the reason, versus a nonzero code that only surfaces an error to the human without blocking, and confirm the script uses the blocking one deliberately, not by accident.

CONSTRAINTS
- The check inside the script must be based on the actual command content in the tool input, not just the tool name — a hook that blocks every Bash call because one specific command is dangerous is a blunt instrument that will also block every safe git status and ls the agent needs to run.
- Fail closed, not open: if the hook script itself errors, or the payload is malformed in a way that makes the check inconclusive, the default should be to block and say why, not to silently allow the action through.
- Do not make the block message vague. A bare 'this command is not allowed' gives the agent nothing to work with; state the specific pattern matched and, if git push --force-with-lease, which the team already permits on feature branches exists, name it directly so the agent can retry correctly instead of guessing at a workaround.
- Test the hook against both a case that should be blocked and a case that looks similar but should be allowed, and show both example payloads and the script's actual exit code for each.

OUTPUT
The settings.json fragment, the hook script in full, and the two test cases with their outcomes.