backlog: file #1097, the worktree gate's interpreter recursion misses PowerShell flag prefixes (live fail-open)

[wshallwshall]

Authored by the session in worktree nice-payne-4dcee0; pushed and opened by the coordinator. Docs only
-- one BACKLOG item, +28 lines. The fix is deliberately not in this PR.

The defect, and it is LIVE on the installed gate

worktree_gate.ps1 recurses one level into an interpreter argument, because that argument is quoted but
is code that runs. The recursion keys on a fixed alternation:

'(?:^|\s)(?:-c|-lc|-ec|-Command|-EncodedCommand)\s+"([^"]*)"',
"(?:^|\s)(?:-c|-lc|-ec|-Command|-EncodedCommand)\s+'([^']*)'",

PowerShell accepts any unambiguous prefix of a parameter name. So spellings exist that execute and are
not on that list -- and their argument is then blanked as an ordinary quoted span, which makes its contents
invisible to every rule, not only rule 3c.

Coordinator verification -- reproduced independently, not taken on report

1. Which prefixes actually execute (harmless Write-Output PREFIX_RAN payload):

flag	executes	recursed into by the gate regex
-Command	yes	yes
-Comm	yes	NO
-Com	yes	NO
-Cm	no (ambiguous)	n/a
-C	yes	yes (matches -c)

So the bypassing family is bounded -- -Com, -Comm, and the intermediate spellings up to -Command --
which is what makes this fixable rather than open-ended.

2. Regex confirmation, [regex]::IsMatch(..., 'IgnoreCase') on pwsh -NoProfile <flag> "git reset --hard":
-Command True, -C True, -Comm False, -Com False.

3. It is LIVE, which required checking the INSTALLED copy rather than the source. The gate executes
from C:\Users\Scott\.claude\hooks\worktree_gate.ps1 (per the settings.json hook wiring), 93,581 bytes,
last written 2026-08-07 11:19. LF-folded, it is byte-identical to scripts/hooks/worktree_gate.ps1 in
this checkout and carries the same fixed alternation. This repo has measured genuinely stale installed
hooks before with zero instruments watching them, so "the source is wrong" and "the live gate is wrong"
are separate claims; both hold here.

The obvious fix is insufficient, and that is the load-bearing part

Adding the three spellings to the list closes every form on the committed gate, but on a
message-blanking gate it closes only the single-line form and leaves the here-string route open behind it.
The here-string form denies today only by accident -- every line of a multi-line span reaches the
scanner raw -- and that accident is removed by any correct message-blanking change.

So the fix must be verified against the gate as it will SHIP, not as it is today.

Why the #1086 fix was reverted, and the lesson worth carrying

The #1086 work is banked, not abandoned. It was rejected because two of three verifiers independently found
a new fail-open in it; the design was right (key on the consuming flag, blank after interpreter
recursion, both pinned by killed mutants) and only the classifier was wrong -- one open-ended cluster regex
matched -Com. Two verifiers measured the closed-flag-set replacement as returning the bad rows to DENY
with zero other verdict movement, so it is resumable (resumeFromRunId: "wf_b4050e2f-77d", re-apply the
banked patch first).

The third verifier ACCEPTED it -- because its corpus contained no -Com payload. Its evidence could
not see the class it was accepting. That is #1000's shape occurring inside the verification of a #1000
fix. Do not read "one verifier accepted" as evidence; read what its corpus covered.

Claim 1086 remains held by nice-payne-4dcee0.

Auto-merge not armed -- queued behind merge train #275. Docs-only, so it costs no CI slot when its turn
comes.