ci: cancel a PR's superseded test run when its head moves (#848)

[fujibee]

Part of #848 — the part that costs nothing. Twelve lines of tests.yml: a concurrency group keyed by PR number, with cancel-in-progress for pull_request events only.

Why this, and why today's numbers say so

Measured on 2026-08-21 from the tests workflow's job timestamps (the full table, with the other directions and what each does and does not fix, is on #848):

• 35 tests runs were created that day — 28 pull_request, 7 push — each with four macOS shards: 140 macOS jobs, averaging ~13 min.
• The most macOS jobs ever observed running at once was 5. That is the account's runner ceiling, and it turns 140 jobs into roughly six hours of serialized macOS time.
• It shows up as queue wait, not runtime: macOS shards waited 0–50 min to start; one PR's shard 3/4 waited 50 min; at 20:40Z three main runs created after 19:18Z had not started a macOS job yet.
• Several of those runs were superseded: the same PR's head moved two or three times during review, another was rebased — and each superseded run kept its four slots until it finished. Nothing cancels them, because tests.yml has no concurrency: group.
• The shard cap (ci: macOS shard runtime has outgrown the 25-minute cap — adding tests can re-pack a shard over the cliff (wall-clock cancel of a passing shard, not a hang) #848's original subject) is not what bit: it is 30 min since fix(watch): fold sentinel '-' into the empty session-id path #857, and the heaviest macOS shard ran 22–25 min all week; the three test files added that day cost seconds.

A run whose head has moved cannot be used for anything — not a review verdict (those name the head), not the merge gate — so cancelling it loses nothing and frees four macOS lanes out of five.

What it does not do

• It does not cancel push runs. Their group is tests-<run id>, one run per group, so a push to main always runs to completion; that run is what a release reads.
• It does not touch shard packing, runtime weighting, the cap, or which PRs get macOS. Those are the other rows in the table on ci: macOS shard runtime has outgrown the 25-minute cap — adding tests can re-pack a shard over the cliff (wall-clock cancel of a passing shard, not a hang) #848, each of which fixes a different thing and one of which (macOS only on main) would have hidden the day's most useful failure (The SQL quote helper is wrong on bash 3.2, and its only caller is skipped on the platform where it breaks #928) until after merge.

No before/after measurement is possible for this one — the effect is on the next batch of concurrent PRs — which is why the numbers above are the justification rather than a result.