ci: scan every main push and use shallow verify checkouts

[altaywtf]

Summary

Every main push now finishes its CI run, so the secret and workflow scan covers each pushed range, and verification checks out one commit instead of full history.

	Before	After
Push and dispatch runs	one CI-refs/heads/main group; a third push cancels the pending second run, whose range is never scanned	one group per run; every pushed range is scanned
Pull request runs	superseded runs cancelled	unchanged
verify checkout	full history	default depth

Risks

• Releases stay serialized by the shared release workflow's own release-<repo>-main group, which keeps full history for semantic-release. That group holds one pending release, so if three pushes land within one release and the older verify finishes last, semantic-release skips the stale commit and the newer commits publish on the next push.
• The scan deepens its own clone to the pushed range, or to full history on dispatch.

Verification

• The scan passes through on pull requests; actionlint 1.7.12 and zizmor 1.29.0 report nothing on this branch locally, and the first main run after merge audits the change.
• Merging runs verify and the release job on main; a ci: commit publishes nothing.

Follow-Ups

None.

---

Written by an agent (Claude Code, Claude Opus 5.5)

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Copilot]

Copilot review overview

🔵 Needs a closer look

It alters CI concurrency grouping whose correctness depends on the release pipeline's serialization behavior, and publishing mistakes are irreversible, so a human should confirm before approval.

Review effort: Balanced
Findings: None

What changed in this PR

This PR adjusts the CI workflow so that every push to main completes its own run, ensuring the secret/workflow scan audits each pushed commit range, and so the verify job uses a shallow checkout instead of fetching full history.

Previously, push/dispatch runs shared a single ${{ github.workflow }}-${{ github.ref }} concurrency group; because queued runs are superseded, a rapid third push could cancel a pending second run and leave that commit range unscanned. The new expression keeps ref-based grouping (and cancellation) only for pull requests and switches push/dispatch to the unique github.run_id, so each push runs independently and is fully scanned. Removing fetch-depth: 0 is safe because the shared scan action deepens its own clone to the pushed range (or unshallows on dispatch), vp run verify needs no git history, and the separate reusable release workflow keeps its own fetch-depth: 0 plus a release-<repo>-main concurrency group that serializes releases.

Changes:

• Group push/dispatch CI runs by github.run_id (unique per run) while keeping PR runs grouped by ref, so every pushed range is scanned rather than superseded.
• Drop fetch-depth: 0 from the verify job checkout, relying on a default shallow clone.

File	Description
.github/​workflows/​ci.yml	Event-aware concurrency group so main pushes aren't cancelled, and a shallow checkout for the verify job.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.