Fix missing-workflow-permissions alerts and integrate zizmor

[dduugg]

Summary

Resolves 6 of the 7 open code scanning alerts (https://github.com/rubyatscale/visualize_packs/security/code-scanning), all actions/missing-workflow-permissions findings on workflow jobs that had no explicit permissions: block and so defaulted to the repository's token permissions:

Alert	File	Fix
#8, #9, #6	ci.yml (3 jobs)	root-level contents: read — checkout + bundle exec only, nothing writes
#3	cd.yml	contents: write on the caller job — the called reusable workflow pushes a release tag (discourse/publish-rubygems-action) and creates a GitHub release (gh release create), both need contents: write
#1	stale.yml	issues: write + pull-requests: write — required by actions/stale
#2	triage.yml	issues: write — matches what the called reusable workflow's own job declares

The 7th alert (js/functionality-from-untrusted-source, the insecure http://d3js.org/d3.v3.min.js CDN tag) was already fixed by #112 (merged), which deleted the file that alert pointed at — CodeQL just hasn't rescanned main yet, so it still shows as open.

Also adds .github/workflows/zizmor.yml, copied from shared-config's existing zizmor integration (the org's canonical pattern — this is the first consumer repo to adopt it). Running it locally against this repo's own workflows surfaced real findings beyond CodeQL's coverage, fixed here so the new job starts green:

• Unpinned actions/checkout@v4 / ruby/setup-ruby@v1 in ci.yml — pinned to SHA, matching codeql.yml's existing convention.
• Missing persist-credentials: false on checkout steps in ci.yml and codeql.yml.
• A stale version comment in codeql.yml (said # v3.37.3, the SHA is actually v4.37.3 — a leftover from an earlier find-and-replace across the org).
• Three findings suppressed with # zizmor: ignore[...] for deliberate, org-wide conventions rather than bugs: workflow_run-triggered CD (dangerous-triggers), unpinned @main references to shared-config's reusable workflows (unpinned-uses — pinning these would defeat the point of centralizing them), and secrets: inherit on the cd.yml caller (secrets-inherit, matching shared-config's own precedent).

Verified with zizmor .github/workflows/, both offline and with --gh-token (online mode catches additional findings, like the stale version comment, that offline mode misses): 0 findings.

⚠️ Separate, pre-existing issue found during verification (not fixed by this PR)

Independent verification surfaced a real, currently-active bug in shared-config's own cd.yml (not touched by this diff): its checkout step sets persist-credentials: false, but discourse/publish-rubygems-action's rake release step does a raw git push that depends on that persisted credential. This means granting contents: write here is necessary but not sufficient — the actual deploy will still fail.

This isn't hypothetical: rubyatscale/danger-migrations (which calls the same shared-config/cd.yml@main) has failed 9 of its last 10 CD runs since 2026-04-14 with fatal: could not read Username for 'https://github.com'. visualize_packs's next real gem release will very likely hit the same failure. Fixing it requires a change to shared-config itself (e.g. dropping persist-credentials: false on that checkout step, or re-authenticating before the push), which is out of scope for this PR.

Test plan

• zizmor .github/workflows/ — 0 findings, offline and online
• All 6 changed/added YAML files parse correctly
• Each permission grant independently verified against what the called reusable workflow / action actually requires (not just copy-pasted from CodeQL's generic suggestion)
• Confirm alert Remove dependency on package_protections #7 auto-closes once CodeQL rescans main

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.