Add zizmor to CI/security scans for GitHub Actions static analysis

## Summary

Wire [zizmor](https://docs.zizmor.sh/) — a purpose-built static analyzer for GitHub Actions — into the repo's tooling so workflows are scanned for security issues (template/script injection, dangerous triggers, credential persistence, excessive permissions, unpinned actions, etc.).

## Motivation

While remediating a script-injection vuln in `merge-prevention.yml` (CWE-78, PR #222) we found zizmor is **not installed or referenced anywhere** — not in `mise.toml`, `.pre-commit-config.yaml`, or CI. It would have flagged that finding automatically, and it caught a latent invalid-`if:`-expression bug during that work.

## Scope — all three layers (match the existing scanner pattern)

Every other scanner (bandit, semgrep, checkov, gitleaks) lives in all three layers; zizmor should too:

- [ ] **CI** — add a `zizmor` job to `.github/workflows/security-scanners.yml`, mirroring the bandit/gitleaks pattern (upload results to code scanning).
- [ ] **mise** — add `security:zizmor` task; include in the `security` aggregate (which `build` runs).
- [ ] **pre-commit** — add the official hook (`zizmorcore/zizmor-pre-commit`), naturally scoped to workflow files.

## ⚠️ Key obstacle: pre-existing findings

A baseline run (zizmor 1.26.1, default persona, `--offline`) over `.github/workflows/` reports **72 findings: 1 high, 12 medium, 3 low, 7 informational** (rest suppressed). The single **high** is `dangerous-triggers` — `pull_request_target` in `pull-request-lint.yml`.

This means zizmor **cannot be a blocking gate on day one** without first triaging/fixing that backlog. Introduction strategy (pick one):

1. **Advisory first** — run + report (upload SARIF to code scanning) but non-blocking; burn down findings in follow-ups; flip to blocking later. *(Recommended — standard "new scanner vs. existing backlog" playbook.)*
2. **Blocking immediately** — triage all 72 (fix or document per-finding ignores via `.github/zizmor.yml`) in the same PR, then gate. Larger, riskier (touches many unrelated workflows).

## Notes

- CLI emits `plain`/`json` only (no native SARIF in 1.26.1); the official `zizmorcore/zizmor-action` handles SARIF conversion for code-scanning upload.
- Runs with zero repo dependency via `uvx zizmor` (same ephemeral pattern as pytest).
- Related: PR #222 (injection fix), PR #224 (gitleaks scope).

Start by reviewing the existing scanner jobs in .github/workflows/security-scanners.yml, the security task aggregate in mise.toml, and .pre-commit-config.yaml. Review the reported baseline findings and choose the advisory or blocking introduction strategy. Done means zizmor is represented in all three layers, scans workflow files, and its results are reported appropriately in code scanning.

Written by the indexing model from the issue text.