guardrails: block-noncanonical-commit remediation is bash-heredoc-only — unusable from PowerShell

[kyle-sexton]

Parent

Refs #912 (audit umbrella; finding F3).

What to build

block-noncanonical-commit.sh's BLOCKED remediation text tells the caller to use git commit -F - --cleanup=verbatim <<'EOF' … EOF — a bash heredoc that does not run in PowerShell or cmd. On Windows-primary machines (PowerShell tool primary; and after #915 broadens the matcher, PowerShell-tool traffic hits this guard directly) the remediation is unusable as pasted.

Make the remediation shell-agnostic or shell-aware: either present both forms (bash heredoc + PowerShell pipeline equivalent, e.g. a here-string piped to git commit -F - --cleanup=verbatim), or detect the invoking tool (tool_name in the hook payload) and tailor the snippet. Keep the /commit-skill pointer first — it is shell-neutral.

Acceptance criteria

• A blocked PowerShell-tool (or Windows) caller receives a remediation snippet that runs in PowerShell
• Bash callers still receive the working heredoc form
• Test asserts remediation content per invoking-tool context
• Guardrails version bump + CHANGELOG entry (may batch with sibling guardrails fixes in one wave)

Blocked by

• fix(guardrails): close PowerShell-tool bypass of Bash-matched guards #915

[kyle-sexton]

Delivered inside PR #960 (the #915 fix): block-noncanonical-commit's remediation is now shell-aware — PowerShell-tool callers get the here-string form (@' … '@ | git commit -F -), Bash callers keep the heredoc; block-hook-bypass and block-dangerous-git block messages are shell-agnostic, and ps::print_unparsable_block_message owns the PS wording. Test: 'PS write block message is shell-agnostic' + block-message assertions in block-noncanonical-commit.test.sh. Shipped in guardrails 0.10.3.