Never cancel a Type label run

[lamemustafa]

Part of #1183

Outcome and reason

Two armed pull requests (#1180 and #1186) sat BLOCKED with every required check green except Type label. A pull request gets several events within a second (opened, then one labeled per label), and the workflow's concurrency group cancelled the older runs. Each of #1180 and #1186 had three successful and three cancelled Type label runs on one commit. Over 194 merged pull requests, 25 merged with a cancelled run beside a successful one, so a cancelled run alone does not block; the data fits one rule: the result that counts is the newest run (highest run id). On #1180 the newest run was cancelled before it started a job, because the runs reached the group in a different order from their creation, and the pull request stayed blocked until the newest run was re-run (re-running older runs did nothing). The group now queues every run, so the burst runs in order and this group cancels none of it.

Scope, reuse, and impact

• Scope: .github/workflows/pr-labels.yml concurrency only: cancel-in-progress: false and queue: max (the same keys tax-audit-mutations-nightly.yml:30-31 uses at workflow level for the same reason, and ci.yml:913 at job level; on this repository, three back-to-back dispatches of the nightly workflow showed two runs pending together instead of the newer cancelling the older), plus an assertion of the group in the workflow's existing test. The merge-queue half of the workflow keys its group on the run id and is unchanged. Excluded: the label check itself and its script.
• Existing component reused: queue: max (verified on this repository by the nightly workflow). What is deleted: the cancel-in-progress expression. What breaks if this is not built: armed pull requests keep stalling silently, and each stall needs a hand re-run.
• Net LOC (production, tests): +7/-1 in the workflow (5 of them a comment), +3 in the test.
• Source issue: CI: shorten the pull-request critical path #1183. Migration and rollback: revert the commit. Destructive database migration: No. Security impact: none; permissions, triggers and the check are unchanged.

Validation and evidence

• Exact candidate SHA: filled in at push.
• node --test scripts/check-pr-type-label.test.mjs: 4 passed; with the previous workflow file restored the new assertion fails (3 passed, 1 failed).
• Check-run listings read from the Checks API for Say the configured row limit can cap the log tools' limit, and name receipt lines (#1157 follow-ups) #1180 and Make comment lines at step indentation part of a pinned step's text #1186 (above).
• Not established: GitHub does not document how a required check with several runs is evaluated; the newest-run rule above is inferred from the check-run listings, not stated by GitHub. Effect of this change is not yet observed: this pull request's own label burst is the first sample (expect N successful runs, none cancelled, run one after another). A run can still end cancelled by its 3-minute timeout or a manual cancel, and a re-run of a run created before this merges keeps the old behaviour.
• Latency: runs now wait behind each other, so Type label settles later within a burst. Measured over 31 successful runs: median 32 s, p90 105 s, max 247 s each; the required Required checks takes about 20 minutes, which hides it. queue: max holds up to 100 waiting runs.
• Platform evidence: not applicable (a Linux workflow).
• Review checklist line linked: https://github.com/ComplyEaze/bridge/blob/8deefadd9/review-checklist.md (Privacy and security checks: nothing sensitive in published text)
• Native Windows validation: not applicable
• Native macOS validation: not applicable

🤖 Generated with Claude Code

[lamemustafa]

Independent review (local, Opus) of 161f86a

Verdict: no P1/P2; 1 optional P3. Workflow and test only; no pinned path.

1. The change fixes the cause the stalls showed. I read the check runs on the stalled heads myself. On Make comment lines at step indentation part of a pinned step's text #1186 the highest-id PR labels run (37226761932) had ended cancelled, and the PR entered the queue right after that run's re-run succeeded. On Say the configured row limit can cap the log tools' limit, and name receipt lines (#1157 follow-ups) #1180 the highest id (37224982614) was cancelled while a lower one had succeeded. Queuing runs instead of cancelling them removes that state.
2. Correctness does not depend on run order. Each run checks the labels in its own event payload, so the newest run reflects the newest labels whichever order the queue runs them in. The merge-queue branch of the group keys on github.run_id and is unchanged. queue: max is the form master already uses at tax-audit-mutations-nightly.yml and at ci.yml:913.
3. The pin works. I ran node --test scripts/check-pr-type-label.test.mjs on a copy of this head: 4/0. With master's pr-labels.yml restored it gives 3/1, failing only the workflow-shape test, so the new assertion fails first.
4. Live sample: at 20:29Z this PR's own label burst showed three PR labels runs at once, one in progress and two pending, with none cancelled. That is the behaviour the body predicts. The burst's final conclusions are the evidence to cite.

Optional P3: the body says "+8/-1 in the workflow (6 of them a comment)". --numstat gives +7/−1, of which 5 are comment lines.