ci: add zizmor static analysis workflow (#1012)

* ci: add zizmor static analysis for workflows

Runs zizmor (https://docs.zizmor.sh) on every PR that touches workflow
or zizmor config files, and on every push to main. Findings upload to
the Security tab via SARIF; the workflow itself never fails (per
zizmor-action's recommended Advanced Security mode -- gate merges with
a code scanning ruleset if desired).

The zizmor.yml at the repo root ignores a small, deliberately-chosen
set of findings:

- dangerous-triggers: pull_request_target / workflow_run on the six
  workflows that use them defensively (don't execute PR code; only
  inspect metadata or apply pre-vetted artifacts).
- excessive-permissions on cla.yml: the third-party CLA assistant
  action needs the listed scopes; the workflow has one job that uses
  all of them.

Everything else (template-injection, artipacked, secrets-inherit,
use-trusted-publishing) stays visible. With the upstream fixes in
#1009 applied, the baseline is 0 High / 10 Medium / 13 Informational --
all advisory, all worth surfacing.

* ci(zizmor): move config to .github/zizmor.yml, tidy trigger

Addresses Copilot review on #1012:

- Move zizmor.yml from repo root to .github/zizmor.yml. The workflow's
  paths filter already pointed at .github/zizmor.yml, and zizmor
  auto-discovers either location; co-locating with the workflows makes
  the relationship obvious.
- Drop branches: ["**"] on pull_request (default is all base branches).
- Drop the zizmor.yml path entry (the config no longer lives there).

Author: ascorbic

.github/workflows/zizmor.yml

@@ -0,0 +1,28 @@
+name: zizmor
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    paths:
+      - ".github/workflows/**"
+      - ".github/zizmor.yml"
+
+permissions: {}
+
+jobs:
+  zizmor:
+    name: Run zizmor
+    runs-on: ubuntu-latest
+    permissions:
+      security-events: write # upload SARIF to code scanning
+      contents: read
+      actions: read
+    steps:
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+        with:
+          persist-credentials: false
+
+      - name: Run zizmor
+        uses: zizmorcore/zizmor-action@b1d7e1fb5de872772f31590499237e7cce841e8e # v0.5.3

.github/zizmor.yml

@@ -0,0 +1,47 @@
+# Configuration for zizmor (static analysis for GitHub Actions).
+# https://docs.zizmor.sh/configuration/
+#
+# Findings ignored here are *deliberate* design choices, not "TODOs we never
+# got to". Anything new or unexpected should land as a finding in the Security
+# tab and be triaged before merge. Add an entry here only with a comment
+# explaining why the finding is acceptable.
+
+rules:
+  # `pull_request_target` and `workflow_run` are inherently dangerous, but we
+  # use them in workflows that have been written defensively: they either
+  # don't run untrusted code from the PR head, or they isolate untrusted state
+  # into clearly-marked steps. Each entry below has a one-line justification.
+  dangerous-triggers:
+    ignore:
+      # CLA assistant must comment on PRs from forks; runs a pinned third-party
+      # action and does not execute any code from the PR.
+      - cla.yml
+      # Auto-format runs against trusted same-repo branches only (gated by
+      # `github.event.pull_request.head.repo.full_name == github.repository`
+      # downstream). Fork PRs are routed through format-command instead.
+      - auto-format.yml
+      # Lunaria only reads localized content and posts a status comment; does
+      # not execute PR-controlled code.
+      - lunaria.yml
+      # pr-compliance and pr-triage only inspect PR metadata (title, labels,
+      # author) via github-script. They never check out PR code.
+      - pr-compliance.yml
+      - pr-triage.yml
+      # query-counts-apply uses workflow_run to apply snapshot updates that
+      # were computed in the untrusted `query-counts` workflow. The trusted
+      # workflow only consumes the artifact JSON, verifies the head SHA, and
+      # pushes back via an app token. See workflow comments for the full
+      # threat model.
+      - query-counts-apply.yml
+      # query-counts-label labels PRs based on path filters; it does not
+      # check out PR code.
+      - query-counts-label.yml
+
+  # The CLA assistant action (contributor-assistant/github-action) requires
+  # write access to actions, contents (cla-signatures branch), issues, PRs,
+  # and statuses. The workflow has only one job that uses these permissions,
+  # so workflow-level vs job-level scoping makes no real difference. A future
+  # PR may split the `label` job to a separate file with narrower permissions.
+  excessive-permissions:
+    ignore:
+      - cla.yml