Run zizmor on the GitHub Actions workflows in CI

[PhiLily]

Every action in .github/workflows/ is pinned to a commit SHA, but nothing checks the workflows for the rest of what zizmor audits. As discussed in #44, the job should run zizmor with its default settings rather than a config that loosens them.

Running zizmor 1.30.1 with default settings on main today reports 15 findings:

• 14 artipacked: actions/checkout without persist-credentials: false. 9 are in ci.yml, 4 in security.yml and 1 in release.yml. No workflow pushes with git, so none of them needs the credentials kept.
• 1 template-injection (info) in ci.yml: the ci-ok job expands toJSON(needs) straight into an echo in its script.

The work is to fix those findings and then add a zizmor job that fails when zizmor reports anything.

Where to look:

• .github/workflows/ci.yml, security.yml and release.yml for the checkouts. Add persist-credentials: false under with: on each.
• The ci-ok job in ci.yml. Pass toJSON(needs) in through env: and read the variable in the script instead of expanding it inline.
• The secrets job in security.yml shows how a tool is installed here: pinned by version and by the sha256 from the release's checksums file. Install zizmor the same way, or use zizmorcore/zizmor-action pinned to a commit SHA with its version in a comment.
• Keep the workflow-level permissions: contents: read.

If a finding is accepted on purpose, say why in an inline ignore comment on that line (for example # zizmor: ignore[artipacked] and the reason) rather than disabling the rule for the repository. No .github/zizmor.yml that turns rules off or relaxes pinning.

Out of scope, for follow-ups: secrets-outside-env on context7-refresh.yml, which needs a repository environment that only a maintainer can create, and the findings zizmor only reports with --persona auditor, such as the service container images in ci.yml.