feat: add zizmor audit job to CI quality workflow

[planetf1]

Summary

Closes #331

Adds a zizmor static analysis job to the reusable quality.yml workflow, which runs on every PR via ci.yml. The job fails on findings, blocking PR merges natively — as requested in the issue.

Changes

Single job added to .github/workflows/quality.yml, modelled on the existing actionlint job:

zizmor:
  runs-on: ubuntu-latest
  permissions:
    contents: read
  steps:
    - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
      with:
        persist-credentials: false
    - name: Audit GitHub Actions workflows with zizmor
      uses: zizmorcore/zizmor-action@3dc1ecc9bcb9e94e9b2c709687979e1298497054 # v0.6.2
      with:
        advanced-security: false
      env:
        GH_TOKEN: ${{ github.token }}

Design decisions

• advanced-security: false — job fails on findings, which natively blocks the PR. The Advanced Security mode (SARIF upload to Security tab) does not fail the job by default and would require a separate repo ruleset to gate merges.
• GH_TOKEN from github.token — enables online audits (impostor-commit, ref-confusion, typosquat-uses, known-vulnerable-actions). Uses the ephemeral per-job token, not a stored secret. Scoped to contents: read by the permissions: block.
• SHA-pinned at v0.6.2 (3dc1ecc9...), matching the supply-chain discipline of the rest of the repo.
• No new violations — the existing # zizmor: ignore[] annotations on hold.yml, pr-label.yml, pr-update.yml, and the HF_TOKEN steps cover all known intentional exceptions. zizmor reports 5 suppressed, 0 findings.

[jakelorocco]

Since this is added as a part of the quality.yml, does this mean it will run on release CI/CD as well? I'm not sure it matters but that might be unnecessary and we should make sure that we can still push through a release if this check fails.

[markstur]

I think the "issue to be filed" placeholders should be filled out before merging otherwise why comment.

The other concern is whether this should be merged before some of those are fixed. Ideally a few of those existing issues would be fixed before this is merged (basically as part of testing this), but exactly how reasonable that effort is I don't know. It makes sense that at some point we merge this with issues created to fix the existing problems.

[planetf1]

@markstur Filled in the zizmor.yml placeholders in 2464f43: ref-version-mismatch→#1533, unpinned-uses/github-app→#1531, template-injection→#1532, cache-poisoning/excessive-permissions/artipacked→#1534 (mapping from #331). Each issue's DoD is fix + remove the suppression.

@jakelorocco fair point re release CI — in 950a82d, moved the zizmor job out of quality.yml into its own reusable workflow (actions-audit.yml), wired into ci.yml (PR gate) only, not into publish-release.yml's code-checks. zizmor audits the workflow files, not the code being released, so a new finding there shouldn't be able to block a release.

[ajbozarth]

Some feedback from Claude:

Nice — design is sound (separate actions-audit.yml off the release path, SHA-pinned, correctly scoped perms), and all four tracking issues (#1531–1534) exist and map to the right suppression groups. Verified locally with zizmor v1.29.0: config passes clean at 20 ignored, 36 suppressed. One cleanup below.

[planetf1]

I’ve removed the unnecessary suppression - should be good to go with a review