CI: main-branch pushes need a concurrency group; bulk merges stall the runner queue

[godofecht]

Operational, observed repeatedly during the recent campaign.

The problem

Every merge to main fires the Flow and Remaining issue implementation workflows. During bulk merge windows the queue saturated with runs for superseded main SHAs — at its worst, 100 queued / 0 in progress — starving PR checks. Superseded runs had to be hand-cancelled five separate times (127 runs in one pass alone). Only the newest main SHA's result ever matters; every intermediate run is waste.

The fix

concurrency groups with cancel-in-progress: true scoped to the main push trigger, in both flow.yml and disparity.yml:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.ref == 'refs/heads/main' }}

The conditional matters: PR branches should not cancel-in-progress (a force-push mid-run is fine to supersede, but the default per-ref grouping already handles that), while on main each new push should kill the previous run outright.

Cautions

• remaining-issues.yml already restricts its push trigger to main (fix: make the disparity gate one-sided and hardware-aware (#351, #373) #401) and its freeze-results job has its own concurrency group plus rebase-and-retry for the push race. Do not disturb that; this issue is about the other two workflows.
• pages.yml already has concurrency: group: pages with cancel-in-progress.
• One subtlety: freeze-results pushes evidence commits to main with [skip ci], so those do not compound the problem — verify the skip marker still holds after any change.