CI: a kicked merge-queue entry's dead run holds the concurrency group of its re-enqueue #5381

A merge-queue entry that is kicked and re-enqueued on the same base gets the SAME ref (gh-readonly-queue/main/pr-<N>-<base oid>), so its new merge_group run lands in the same CI concurrency group (ci-${{ github.event.pull_request.number || github.ref }}) as the dead run. cancel-in-progress is true only for pull_request, so the new run QUEUES behind the dead one.

Measured 2026-10-15: run 38693636752 (pr-5369-8f601caff2…, created 06:38:37Z) kept running after #5369's kick; the re-enqueue run 38694775126 (same ref, created 06:49:44Z) sat pending about 31 min.

Fix: cancel-in-progress also true for merge_group. Same ref = same (PR, base) entry, so the newer dispatch always supersedes. Distinct stacked entries have distinct refs and never share a group. pull_request, push, tag and workflow_dispatch behaviour unchanged. A case-table guard (scripts/check_ci_concurrency_cancel.sh) pins all of that and proves the table turns RED on the old expression and on an unconditional true.

done_when: the guard is green on main's ci.yml and its self-test kills both mutants.