fix(governance): lockfile-aware SHA-pin check for consumer repos

[hyperpolymath]

The governance-reusable greps consumer workflows for 40-hex pins, which fail-flags every repo that adopted actions.lock (the locker's canonical output is tag-style refs with SHAs held in the lockfile the runner enforces). First seen on haec: after its lockfile revival (haec#46/#48/#50), Governance metadata was its only red — from this check.

With a lockfile present the step now verifies coverage via gh actions-lock --verify-local (offline) and keeps the inline-SHA demand only for cross-repo reusable workflow calls, which stay outside lockfile scope. Repos without a lockfile keep the exact old grep.

Downstream plan: once this merges, every open estate lockfile PR gets re-pinned to the resulting SHA so their Governance checks pass on first run.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review ✅ Approved

Makes the governance SHA-pin check lockfile-aware for consumer repos by verifying local coverage when an actions.lock file is present. No issues found.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

---

Important

Your trial ends in 6 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}