cancel-in-progress: false does not keep a main run alive, and 27 workflows say it
does. GitHub cancels any PENDING run in a concurrency group as soon as a newer one
is queued; cancel-in-progress governs only runs already executing. The reference is
explicit: 'any existing pending job or workflow in the same concurrency group will
be canceled and the new queued job or workflow will take its place.'

So on main, where pushes land in bursts, the runs in the middle of a burst are
cancelled regardless. Both incidents this repo wrote down are that: studio-ui-smoke
records a break sitting on main for 14 hours behind four cancelled runs, and the
comment added to prevent it cannot. Today four merges in 37 minutes cancelled three
consecutive main runs of Backend CI, which completed none, so main went untested
across the whole batch.

studio-backend-ci.yml and studio-ui-smoke.yml now key their group on github.sha when
the ref is main, so each commit gets its own group and nothing supersedes it. Both
are here because a regression already went unreported behind cancelled main runs of
exactly these two. Pull requests are untouched: the sha term is empty off main, so
superseded PR runs are still cancelled, which is the expensive direction to get
wrong.

The cost is real and worth naming: during a burst, main now runs these two per
commit rather than once at the tip. That is what per-commit attribution costs, and
it is what the incident comments were asking for.

The remaining 26 keep supersession, since paying it repo-wide is not obviously
right, but they stop claiming a protection they do not have.

A guard asserts the two are grouped per commit on main, that pull requests still get
latest-only, and that no workflow claims main protection while sharing a group across
main commits. Each is mutation-checked.

Widened from the two workflows with written-up incidents to all 28 that run on push
to main. Cancelling a pending run is not a saving: the four cancelled Backend CI
runs today recorded ZERO jobs each, so nothing was reclaimed, and main simply went
unverified across five commits.

The two Kaggle workflows are the exception and keep one shared group. They spend an
external GPU quota rather than runner minutes, so a superseded run there genuinely
should be dropped instead of replayed per commit.

The guard is general now rather than a list of two: every workflow triggered on push
to main must be grouped per commit, must still key on github.ref so pull requests
keep latest-only, and must not claim a main protection while sharing a group. It
also asserts the scan found something, since a broken glob would pass everything.

Mutation-checked four ways: reverting one workflow to a shared group, applying
github.sha unconditionally, pointing the exemption at a missing file, and adding the
old claim to a workflow that still shares a group.

for more information, see https://pre-commit.ci

…ard on workflow-only PRs

The predicate was "github.sha" in group, which is not the invariant. Reverse the
conditional to github.ref != 'refs/heads/main' && github.sha || '' and the substring is
still there, every workflow still names refs/heads/main, and main commits share one group
again: the guard passed on the exact regression it exists to catch. It now renders the
group for two SHAs on main and requires them to differ, and for two SHAs on one pull
request and requires them to match, so which branch supplies the SHA is what decides.

The evaluator refuses to guess at syntax it does not model, and a separate test turns that
refusal into a named failure rather than a silent pass.

Also invoke this file from workflow-trigger-lint.yml. It reads every workflow's concurrency
block, so the PR that breaks it edits some other workflow's YAML, and no workflow filters on
.github/workflows/**. A revert of wheel-smoke.yml to a shared main group collected no test
that reads it. The lint job carries no paths filter by design, which is the same reason the
Playwright coverage guard sits there.