check-action-pins-resolve.sh scans prose: a documentation example SHA fails the gate

[hyperpolymath]

Governance Check / Workflow security linter runs check-action-pins-resolve.sh, which
scopes itself to a directory and greps it recursively with no filename filter:

WORKFLOW_DIR="$TARGET/.github/workflows"
grep -rhoE '\buses:[[:space:]]*[A-Za-z0-9_.-]+/[A-Za-z0-9_./-]+@[0-9a-f]{40}' "$WORKFLOW_DIR"

So any file in that directory is scanned, including documentation. In
metadatastician/paint-type, .github/workflows/README.adoc:136 carried an illustrative
- uses: actions/checkout@8e5e7e5ab8b370d3a0e0e70878d379440678a716 # v3.3.0. That SHA does
not exist upstream (repos/actions/checkout/commits/<sha> returns 422 "No commit found for
SHA"), so the gate reported 1 of 3 action pin(s) DO NOT EXIST upstream and went red — on a
prose file, for a pin nothing ever used.

metadatastician/paint-type#86 cured the symptom by rewriting that documentation section. The
gate's scoping is the root cause and is estate-wide: every repository that documents SHA pinning
inside .github/workflows/ is exposed, and the failure names a file no workflow loads.

Worth noting this was masked until recently: the pin step is 5th in the job and the job
halted at step 1, so it reported skipped — unknown, not passing — on every prior run.

Acceptance criteria

• check-action-pins-resolve.sh restricts its scan to workflow files (*.yml/*.yaml),
  not every file under .github/workflows/.
• A regression control: a file named README.adoc in that directory containing a
  fabricated 40-hex uses: line does not fail the gate, while the same line inside a
  .yml file still does. Both directions asserted — a filter that passes everything is
  not a fix.
• The behaviour change is stated in the script's header comment.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YSq3UodR3CjsuAK5yoTzHF