v2.0.7 — guardian judges what runs, not words in data

Castra guardian: rules apply to what a command runs, not to words in its data.

The vendored guardian matched its patterns against the whole command line. Words in data set them off: a drop table in a migration file being written, "credentials" in a code comment, Format-Volume in a handover note, a grep for risky words, getent passwd. A pattern could also run on into the next command, so git push … ; pkill -f vite read as a force push.

Now:

• Here-document bodies written to files, comment lines, and grep/echo segments are left out, unless they reach something that runs them: bash, psql, ssh or powershell bodies, subprocess calls in a Python body, bodies inside $(…), a script written and then run, copied or registered in the same command, or echo … | psql.
• Each rule is checked per command segment. Only pipe rules (curl … | sh) look across segments.
• Key and credential files are judged by the file a command opens, like .env in v2.0.6 / v0.2.2.
• getent passwd and /etc/passwd are no longer read as a credential change.
• Gap closed: git's global options no longer hide the subcommand. git -C <dir> push --force used to pass every git rule; on the author's history four real --force-with-lease pushes went through that way.

Replayed over 58,056 real commands: every downgrade on a hand-off or confirm rule was a word in data. git push --force-with-lease stays a hand-off.

Also: test_forge.py sent one fallback-path reply to the live Jev, which made it flaky; that call now runs without Jev.