ci: scan every main push and use shallow verify checkouts

[altaywtf]

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 and verify-consumer-surface checkouts	full history	default depth

• 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.
• 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.

---

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

Changes to the CI workflow's security-scan history coverage and release-pipeline concurrency warrant final human verification despite no identified defects.

Review effort: Balanced
Findings: None

What changed in this PR

This PR adjusts the CI workflow (.github/workflows/ci.yml) so that every main push completes its run rather than being superseded, ensuring the secret/workflow scan covers each pushed commit range. It also drops full-history checkouts in the two verification jobs, since the shared scan action (v1.2.0) already deepens its own clone to the pushed range (or unshallows on workflow_dispatch). This fits the repo's release/CI model where main pushes gate semantic-release, and releases stay serialized by the shared release workflow's own concurrency group.

Changes:

• Replaced the single per-ref concurrency group with a per-run group (github.run_id) for push/dispatch while keeping per-ref cancellation for pull requests.
• Removed fetch-depth: 0 from the verify and verify-consumer-surface checkouts, relying on the scan action's self-deepening.

File	Description
.github/​workflows/​ci.yml	Scopes concurrency per run for push/dispatch (so no pending run is cancelled before its range is scanned) and switches verify checkouts to default shallow depth.

I verified the key assumptions behind this change: the pinned scan action's plan.sh self-deepens the checkout to before..HEAD (falling back to --unshallow), so dropping fetch-depth: 0 does not starve the secret/workflow scan of history; the verify and test:consumer scripts (vp check/pack/knip/test) require no git history; and the concurrency expression resolves to github.ref for PRs and github.run_id otherwise, matching the described behavior. docs/DISTRIBUTION.md already documents the scan's range/full-history behavior, so no doc update is needed. I found no issues to comment on.

---

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