security-guidance: Stop hook fails with Errno 2 on a file that exists, causing an unbounded asyncRewake loop (Windows / Git Bash / Python 3.14)

## Environment
- Claude Code in the Claude desktop app (Code tab), `local-agent-mode` session
- Windows 11 Enterprise 10.0.26200
- Git Bash (MSYS) as the Bash provider
- Python 3.14 installed via the Python Install Manager:
`C:\Users\\AppData\Local\Python\pythoncore-3.14-64\python.exe`
- Plugin: `security-guidance@claude-plugins-official`

## Symptom
After every assistant turn, the `Stop` hook fails and its `asyncRewake: true`
wakes the model with "Background security review found issues". The reported
finding is just the launcher's stderr:

C:\Users\\AppData\Local\Python\pythoncore-3.14-64\python.exe: can't open file
'C:\Users\\AppData\Roaming\Claude\local-agent-mode-sessions\\_{\rpm\plugin_\hooks\security_reminder_hook.py':
[Errno 2] No such file or directory}

Because the hook fails on *every* Stop, and each failure wakes the model, and the
model's reply triggers another Stop, this becomes an unbounded loop. In my session
it produced one spurious message per turn for ~40 turns across a plain tech-support
conversation with no code in it. Nothing was ever scanned — the "found issues"
summary is only the non-zero exit being reported generically.

## The file is not actually missing
This is the part that distinguishes it from #2043:

- `security_reminder_hook.py` **is present** at that exact path, 111,593 bytes.
- That **same interpreter** opens it fine when invoked manually:

python.exe -c "import os,sys; print(os.path.exists(sys.argv[1]))" ""
# -> True, and open(...).read() returns the file's contents

So the `cygpath -w` conversion added for #2043 appears to be working — the path in
the error is already correct Windows form. The ENOENT is coming from somewhere else
in the launch, not from a POSIX path reaching `python.exe` and not from a genuinely
absent file. Possibly an environment difference between the hook subprocess and an
ordinary Bash tool call (cwd, sandbox/filesystem view, or a race with the per-session
`rpm/plugin_` staging copy).

## Secondary: stale interpreter probe list
`sg-python.sh` pass 1 probes `python3.13 python3.12 python3.11 python3.10`.
Python 3.14 is not listed, so a 3.14-only machine falls through to pass 2 and is
picked up incidentally by bare `python`. Worth adding 3.14 (and ideally deriving
the list rather than hardcoding it).

## Secondary: `if` matcher over-firing
The two `PostToolUse`/`Bash` entries are gated on
`if: "Bash(git commit:*)|Bash(gt create:*)|..."` and
`if: "Bash(git push:*)|Bash(gt submit:*)"`.
They fired — emitting "Commit security review found issues" and "Push security
review found issues" — after ordinary non-git commands (`ls`, `cat`, `grep`,
`find`). No git command was run in that turn.

## Workaround
Editing `hooks/hooks.json` to remove every entry with `asyncRewake: true` (the
`Stop` block and the two `Bash` entries) stops the loop while leaving the
pattern-based `Edit|Write` checks working. Note `enabledPlugins: {"security-guidance@claude-plugins-official": false}`
in `~/.claude/settings.json` did **not** suppress it — the plugin is injected by
the desktop app's session staging rather than via `installed_plugins.json`.

Start by reproducing the Stop hook under Windows, Git Bash, and Python 3.14, then inspect hooks/hooks.json and sg-python.sh, focusing on the staged path, subprocess environment, and asyncRewake behavior. Verify the hook no longer reports ENOENT or loops, the interpreter probe includes Python 3.14, and the PostToolUse/Bash matchers do not fire for ordinary commands.

Escrita pelo modelo de indexação a partir do texto da issue.