ci: add concurrency groups to 78 push workflows

[gHashTag]

GitHub Actions concurrency is billed per account, not per repo. This repo held 431 of the account's 644 queued runs, starving gHashTag/t27 at in_progress=0 for over a day — its four merge-gating contexts could not reach a runner, and no PR there could land.

251 of 427 runs were push-event hygiene workflows with no concurrency group: every push spawned a fresh run and nothing superseded anything. Draining 552 runs freed capacity and seven t27 PRs landed within the hour — then the queue was back to 70 in a single cycle. Cancelling treats the symptom; this treats the cause.

Each file gains, at top level (sibling of on:/jobs:):

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

github.workflow is in the key, so two different workflows on the same ref do not cancel each other. push gives refs/heads/main, pull_request gives refs/pull/N/merge — a push run can never cancel a PR run.

fpga-docker.yml gets cancel-in-progress: false. It is the only push workflow that writes externally (docker/build-push-action → ghcr.io, latest tag); killing it mid-upload can leave a half-pushed manifest. It still gets a group so runs serialize rather than pile up.

Skipped 8: seven have no push trigger; trinity-identity-gate.yml already had a group and is byte-for-byte untouched.

Verified by parsing, not by reading. PyYAML re-parsed all 86 files: concurrency is a top-level mapping key in all 79 push workflows and appears under no job. git diff --stat reports 78 files, 347 insertions, zero deletions — an in-place edit of any trigger, job, step or permission would have registered a deletion.

Honest limits. actionlint is unavailable on this machine, so validation is structural only, not a GitHub schema check. The adversarial verifier confirmed top-level placement on 4 of 78 files before the machine's disk filled; the other 74 rest on the parser sweep alone.

Not merged deliberately — this changes CI behaviour across the repo.

[gHashTag]

Reviewer bee Z: conflicting, and awaiting the owner's workflow scope. 766 commits behind; conflicts with main. Still relevant: 79 of the 78+1 workflows it edits still exist on main, and only 3 workflows on main have cancel-in-progress today. Because the change is mechanical, regenerating it on current main (a script adding the top-level concurrency: block to push-triggered workflows that lack one) is cheaper than resolving 78 conflicts. Cannot be merged with the bee's token (no workflow scope) in any case.

[gHashTag]

Bee review — left open (conflicts) (head 94f042c4ce38)

This is not superseded: none of the 79 workflows touched here has a concurrency: block on main today. Against main, it conflicts in:

• .github/workflows/codegen.yml: content conflict;
• .github/workflows/openxc7-build-timing.yml: add/add conflict (main added its own version).

The other 77 files apply cleanly. I didn't resolve the conflicts: a reviewer doesn't push to the branch. Needs a rebase by the author.

[gHashTag]

Regenerated on current main as #870 (issue #869), as the 2026-10-02 review suggested. It covers 102 workflows today, where this PR covered 78.

#870 changes the key. Here it is ${{ github.workflow }}-${{ github.ref }} with cancel-in-progress: true. That key would:

• let a push to main cancel a workflow_dispatch run in progress on main. 85 of the 102 workflows are dispatchable.
• let a second dispatch cancel the first.
• put conformance-golden-selftests.yml and conformance-selftest.yml, which share one name:, in the same group.

#870 keys on github.workflow_ref instead, gives each dispatch its own group, and cancels in progress only on pull_request.

I have left this PR open. Closing it is the owner's call.

🤖 Generated with Claude Code