Let a newer push cancel the test run it supersedes

The linter has had this since it was written; the suite, which is the
expensive one, never got it. Two pushes landing together ran two full
suites to the end, and the earlier one was checking a subset of what the
later one checks.

Keyed on the ref, so main and a branch never cancel each other, and a
branch with an open pull request does not fight itself — push and
pull_request arrive under two different refs.

One consequence worth stating rather than discovering: on main an
intermediate commit can end up with no run of its own when two pushes
land close together. That is the right trade when what is being verified
is the state of the branch, but it is not free — a bisect or a release
audit that needs a particular commit's own green tick needs that commit
pushed on its own.

.github/workflows/tests.yml

@@ -50,6 +50,23 @@ concurrency:
   group: tests-${{ github.workflow }}-${{ github.ref }}
   cancel-in-progress: true
 
+# A second push supersedes the first — the later run covers a superset of
+# what the earlier one was checking, so finishing both buys nothing and
+# costs a runner.
+#
+# Keyed on the ref, so `main` and a branch never cancel each other. A push
+# to a branch that also has a pull request open produces two events with
+# two different refs, which is why they do not fight either.
+#
+# The tradeoff worth naming: on `main` this means an intermediate commit
+# can end up with no run of its own when two pushes land together. That is
+# accepted here — what is being verified is the state of the branch, and
+# the run that survives is the one that includes both commits. If a commit
+# ever needs its own green tick (a bisect, a release audit), push it alone.
+concurrency:
+  group: tests-${{ github.ref }}
+  cancel-in-progress: true
+
 jobs:
   ci:
     runs-on: ubuntu-latest