fix(guard): mind_commit_guard v1.3 — fail open on shell it cannot attribute (#155)

[Jammy2211]

Build-chain campaign (PyAutoHands#155) remaining-queue item 5.

Evidence. mind_commit_guard has fired live three times and every one was a false positive on its own author — v1.0 on a quoted gh comment body, v1.1 on a cd-away PyAutoHands commit, v1.2 on a for-loop with cd in the body — against zero confirmed catches of a real bad Mind commit. The -- <files> habit has done that work. All three share a root cause: attributing a commit to a repo by parsing arbitrary shell.

Decision (user, this session): narrow, do not retire. docs/agent_failure_modes.md §4 argues a noisy refusal trains bypass-by-default, so the guard may now only DENY when confident.

• New _unattributable(): allow when the command contains a compound keyword (for/while/until/select/case), a subshell or brace group, or a cd at a non-leading clause position (the shape _cd_target silently drops).
• Unchanged: the two high-confidence denials — a git commit unambiguously resolving to a Mind checkout with no -- section, and a directory pathspec after --.
• Quoted text is a single shlex token by then, so a commit message that merely mentions for/done still hits the bare-commit denial (tested).

Verification: 22/22 green (17 existing + 5 new, covering all three historical FPs and re-asserting the simple denials). Also exercised as a live PreToolUse payload through bin/mind_commit_guard.py: the three FP commands return an empty allow, a bare git commit from a Mind cwd still returns the deny JSON.

docs/agent_failure_modes.md mitigation 2 records the outcome and the general lesson: a refusal whose trigger requires modelling an unbounded input space spends its budget on false positives — prefer refusals with a decidable precondition (mitigation 3, which has true-positived).