gateway: emit with.version for known unpinned-tools actions (unblocks #885)

[potiuk]

Summary

#886 tried to silence zizmor 1.25.2's new unpinned-tools audit on 1Password/load-secrets-action with an inline # zizmor: ignore[] comment, but placed it on the if: false line. zizmor only honours the ignore on the line where the finding lives (line 40 — the - uses: line), so the suppression never took effect, and #885 (zizmor 0.5.5 → 0.5.6) has been stuck failing CI ever since.

Why not just move the inline ignore to the right line?

Two reasons:

1. Fragile to dependabot rewrites — the - uses: line already carries dependabot's # v4.0.0 version comment. Dependabot rewrites that comment on every bump and would strip an appended zizmor-ignore tail.
2. No fallback via zizmor.yml config — the zizmor configuration docs state explicitly: "Composite action findings cannot be ignored via zizmor.yml currently. They can be ignored inline [with comments]."

Why pin with.version instead

The audit's actual remediation (per its source at crates/zizmor/src/audit/unpinned_tools.rs) is to set a static with.version value. The audit fires only when the input is missing or set to literal latest. Setting it to any specific string silences the finding cleanly. Since these composite entries are if: false (allowlist registration only — they never execute), the version value is cosmetic; only the static analyser cares.

Changes

• gateway/gateway.py — new _unpinned_tool_version_pin() helper + _UNPINNED_TOOLS_VERSION_PINS table so the composite generator emits a with.version block for any action zizmor's unpinned-tools audit knows about (1password/load-secrets-action today; aquasecurity/setup-trivy preemptive, even though we don't carry it on the allowlist).
• Composite — targeted manual edit applying the same with.version block to the existing 1Password/load-secrets-action and …/configure entries. The next full regeneration (post hotfix: restore ALLOWLIST_WORKFLOW_TOKEN PAT in update.yml (branch protection) #892's pipeline recovery) will produce identical content; the manual edit only fast-paths the fix so build(deps): bump zizmorcore/zizmor-action from 0.5.5 to 0.5.6 in /.github/workflows #885 can land immediately.
• Also drops the no-op # zizmor: ignore[unpinned-tools] tail comment that allowlist: silence zizmor unpinned-tools on if:false 1Password load-secrets-action #886 added on the if: false line — the version pin is the real suppression mechanism now.

Test plan

• Locally with zizmor 1.25.2 (the version bundled by zizmor-action@v0.5.6): zizmor --min-severity medium --min-confidence medium .github/ allowlist-check/ pelican/ stash/ → "No findings to report. Good job!" (down from 1 medium).
• uv run pytest gateway/ → 8 passed.
• Confirmed manual composite edit and a full regen produce identical with.version content for the 1Password entries (the only differences are unrelated version drift from the still-broken update workflow on main — which hotfix: restore ALLOWLIST_WORKFLOW_TOKEN PAT in update.yml (branch protection) #892 will heal).
• After merge: re-trigger build(deps): bump zizmorcore/zizmor-action from 0.5.5 to 0.5.6 in /.github/workflows #885 (@dependabot rebase) → expect Run zizmor 🌈 to pass clean.

🤖 Generated with Claude Code

[potiuk]

Ping @raboof @ppkarwasz @dfoulks1 — this one's blocking #885 (zizmor 0.5.6 bump). Verified locally: zizmor 1.25.2 reports clean on this branch whereas main alone reports 1 medium on the 1Password unpinned-tools audit. Small diff (28 LOC in gateway.py + 4 in composite), CI green. Would appreciate a quick look so the chain can land.