fix: supersede completed backport approval check runs instead of updating them

[claude]

Requested by John Kleinschmidt · Slack thread

Follow-up to #422. Makes the "Backport Approval Enforcement" check create a fresh queued run when the existing run has already completed, instead of attempting an in-place reset that the Checks API silently ignores.

Before

A completed "Backport Approval Not Required" run could not be un-greened. When backport/requested 🗳 landed after the run had concluded, the labeled-event reset from #422 called checks.update({ status: 'queued' }) on the completed run — but the Checks API treats a completed run as terminal, so the PATCH only rewrote the output text while keeping status: completed / conclusion: success. The result was a green check whose output read "Needs Backport Approval", exactly what happened on electron/electron#53035 (check run 96268219963), leaving the PR mergeable without backport approval.

This window is routine for trop-created backports: trop opens the PR first and adds its labels (backport, target branch, backport/requested 🗳, semver) in a separate API call a few seconds later, so the opened-event evaluation from live labels (the #422 fix) genuinely sees no labels and concludes success before the labels arrive.

After

A late approval-request label supersedes the completed run: queueBackportApprovalCheck still resets a run in place while it is queued/in_progress, but when the existing run is completed it creates a fresh queued run — branch protection consults only the latest run per name, so the stale green run no longer gates anything. Additionally, the opened-event evaluation no longer concludes "not required" for any declared backport — a PR whose body carries a Backport of #N declaration, regardless of author; the check stays queued until the labeled events that follow trop's label writes settle the verdict, closing the create-then-label window at the source (and failing safe — pending — if the labels never arrive).

How

• src/utils/checks-util.ts (queueBackportApprovalCheck): keep the fix: evaluate backport approval from live labels to prevent check race #422 dedupe/update path only for runs with status !== 'completed'; otherwise fall through to checks.create with status: 'queued'.
• src/index.ts: in the not-approved/not-requested branch, action === 'opened' no longer concludes for declared backports (getPRNumbersFromPRBody(pr).length > 0). The general rule: a declared backport's labels are always written by trop itself — backportImpl labels trop-created backports in a separate API call after opening them, and updateManualBackport labels manually-opened backports with at least the base-ref label — so every declared backport is guaranteed a subsequent labeled event, and opened can safely leave the check pending for any author and any webhook timing. PRs without a Backport of #N declaration (fast-track / roller PRs targeting release branches) receive this check too but get no guaranteed labeled event and never re-evaluate otherwise, so opened must still conclude "Backport Approval Not Required" for them — always-queue-on-opened would hang those checks forever. As delivery-reordering protection, a late opened does not re-queue a run that an earlier-processed labeled delivery already concluded from the same live labels — superseding it would leave a queued run no follow-up event ever completes.
• Tests: spec/checks-util.spec.ts covers queued/in_progress → checks.update and completed → checks.create (no update); spec/index.spec.ts covers the any-author pending-on-opened rule, the undeclared-PR conclude-on-opened rule, the late-opened no-re-queue rule, and a labeled-event regression test mirroring #53035 (stale completed-success run + backport/requested 🗳 → pending state re-asserted).

Note on the audit of other writes to this check: updateBackportApprovalCheck and the other update*Check helpers always PATCH with a conclusion, i.e. completed → completed transitions, which the API does apply (the validity check has always flipped success/failure this way); only transitions out of the completed state are silently ignored, and the enforcement check's only such transition is the queued reset fixed here. Firsthand evidence from #53035: the queued-reset PATCH succeeded but left status/conclusion/completed_at frozen while applying the new output.

Refs: electron/electron#53035, electron/electron#52973, #422

[dsanders11]

Have some concerns, doing a more thorough review.

Fine for now