ci: scope Quality Gate concurrency to the calling workflow

[szjanikowski]

Problem

After a release, main showed a red ✗ at the release commit — looking like CI was failing. It wasn't. The mark was a standalone Quality Gate run with conclusion cancelled (GitHub renders cancelled identically to a failure). The code was healthy: every other gate run on that commit passed all jobs and the release shipped to PyPI.

Root cause (structural, recurs on every release)

publish.yml calls quality-gate.yml as a reusable workflow (uses:). A reusable workflow's concurrency is evaluated in the caller's ref context. When Publish runs on main, its embedded quality-gate joins the same group quality-refs/heads/main as the standalone Quality Gate triggered by the push to main.

The standard release flow — merge release PR to main (push → standalone gate) immediately followed by a tag push / dry-run dispatch (→ Publish, whose embedded gate shares the group) — therefore triggers cancel-in-progress: true, which cancels the older standalone gate. Red ✗.

Fix

Key the concurrency group on github.workflow as well:

group: quality-${{ github.workflow }}-${{ github.ref }}

github.workflow resolves to the caller's workflow name ("Quality Gate" on a direct push/PR, "Publish" when invoked via uses:), so the standalone gate and the publish-embedded gate never share a group — while each still de-dupes among its own runs (the cancellation savings concurrency was added for are preserved). A comment documents the one caveat: this relies on each caller declaring an explicit name: (both do today), else GitHub falls back to the file path and the group silently changes.

Verification

• YAML parses (quality-gate.yml + publish.yml).
• This PR's own Quality Gate runs and de-dupes on re-push.
• After merge: a dry-run gh workflow run publish.yml --ref main immediately after a push to main no longer cancels the standalone Quality Gate (both complete green).

🤖 Generated with Claude Code