Merging a PR cancels its own in-flight desktop Swift verification, and the closed-event run reports "skipping"

[Git-on-my-level]

#10523 merged a change that does not compile, and main stayed broken for ~12h. The build defect is fixed in the PR that links here; this issue is about the gate that let it through.

Timeline for desktop-swift-ci.yml on agent/m1-studio-codex-terra/5a29ba2b-1784948172 (#10523):

run	conclusion	head	time
30141952816	failure	6109233	03:16
30145497958	cancelled	0b5d4e0	05:17
30145978453	cancelled	73a11a7	05:33
30146418506	cancelled	fe5253d	05:49
30146613315	skipped	fe5253d	05:55:56

The check never passed. The run on the final head SHA was still in flight when the PR merged at 05:55:53, and the merge cancelled it — the closed event lands in the same concurrency group:

types: [opened, synchronize, reopened, closed]
concurrency:
  group: desktop-swift-${{ github.event.pull_request.number || github.sha }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Every job is gated if: github.event.action != 'closed', so the closed run allocates no runner and reports skipping — which is the state gh pr checks 10523 shows today, and which reads as benign.

This is deliberate and contract-tested: test_closed_prs_release_the_same_pr_concurrency_group_without_allocating_a_runner (.github/scripts/test_desktop_swift_ci_contract.py:124), landed in bd93173e8b "ci: bound and retire obsolete Swift PR runs" to stop abandoned PRs holding scarce macOS runners. That goal is right. The problem is that closed does not distinguish abandoned from merged, and for a merge it supersedes the verification of the exact code being landed.

The post-merge push run did catch it (30146613366, failure on 3a63002) — but that signal decays: the two subsequent main runs reported success purely because they touched no Swift and skipped the lane, so after ~40 minutes nothing on main looked red.

Two independent things worth deciding, both above my pay grade to change unilaterally since they trade runner capacity and branch-protection policy:

1. Should cancel-in-progress exclude the merge case (github.event.action == 'closed' && github.event.pull_request.merged)?
2. Should a PR be mergeable while a required macOS check is still pending? It was pending, not green, at merge time.

Evidence commands: gh run list --workflow desktop-swift-ci.yml --branch agent/m1-studio-codex-terra/5a29ba2b-1784948172, gh api repos/BasedHardware/omi/commits/3a63002ea9aba7b63a642065a401ff8aab449fb5/check-runs.