fix(quality): key the concurrency group by event, not by ref alone

[rubenvdlinde]

Implements option 2 from #526.

The problem

A workflow_dispatch run shared a concurrency group with every push run on the same branch:

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

So a run somebody deliberately asked for was cancelled by whatever happened to be merged next.

Measured 2026-08-21 across the 18 core repos: 69% of development push runs (139 of 200) end cancelled, because merges arrive every 8–12 minutes while a run takes 14–23. A dispatched run carried the same odds.

Observed directly today: two dispatched runs on one shillinq commit, one cancelled before it could report.

Two things that were being conflated

• Superseding a push run with a newer push is correct, and is unchanged here: once commit N+1 exists, verifying N matters less.
• Cancelling a deliberate run because unrelated traffic arrived is not supersession — it is losing the answer someone asked for.

Why this blocks #523

The fleet gate-drift sweep exists to prove apps still comply when the gates change and no code did. It dispatches per app with --ref development, because schedule: cannot choose a branch — cron runs from the repo's default branch, and 9 of 18 apps default to main.

Under the old group that sweep would dispatch, be cancelled by the next merge, and report neither pass nor fail. A routine that produces no verdict is indistinguishable from one that was never run — which is the failure mode #523 is already in for a different reason (its token).

Scope, stated plainly

This does not reduce push-side cancellation. That is a cadence problem and a separate decision (#526, where throttling the release loop is option 1 and my recommendation).

It only stops one lane cancelling the other. Lanes are independent: each run provisions its own ephemeral server and database, so there is nothing shared to contend over.

🤖 Generated with Claude Code