ci: name the shard that stopped, and say what cancelled means

[fujibee]

CI only. One file, .github/workflows/tests.yml. Nothing a user installs or runs changes.

What happened

Two pull requests from an outside contributor sat red for a day. Their results:

ubuntu, all four shards      success
Windows, all three legs      success
macOS 2/4, 3/4, 4/4          success
macOS 1/4                    cancelled
bats  (the required check)   failure

The cancelled shard had run for exactly 25 minutes on both — this workflow's
timeout-minutes. GitHub records a job that exceeds it as cancelled, not as
timed out, and the matrix roll-up collapses twelve jobs into that one word.

What the required check said, in full:

::error::the bats shards did not all pass (result: cancelled)

It names no shard. It does not say that cancelled here means a runner limit.
From outside the project, that reads as the repository rejecting the change —
and there is nothing on the page to suggest otherwise, or to suggest a re-run
would help.

The change

The roll-up still decides the exit code. What is added is the job name, and a
sentence that hands the reader the discriminator rather than a conclusion:

Shards that did not pass:
  cancelled	bats (macos-latest 1/4)

A shard whose conclusion is 'cancelled' was stopped rather than failing a
case, and this job cannot tell you why: reaching the 25-minute job cap and
being cancelled from outside the run look identical from here. Open the job
named above. If it ran for about 25 minutes and its log ends mid-suite naming
no failing case, it reached the cap -- which a change that hangs can also
cause, so the cap being reached does not by itself say whose fault it is.

An earlier revision of this PR said more than that: it asserted the cap had
been hit, that the log ended mid-suite, and that the change under test was
innocent. The query observes a conclusion and a job name. It establishes none of
those three, and the last is false precisely when a change hangs and drives its
own shard into the cap — the case where a wrong answer costs the most. Caught in
review.

Best-effort by construction. The listing sits inside an if, so a failed API
call leaves the roll-up's message standing. A diagnosis must never be able to
turn a red into a green, or into a different red.

It needs actions: read, granted at the job. The workflow's contents: read
does not cover the jobs endpoint; without the grant the call is a 403 the step
swallows.

The listing proves it can see, on every run

It runs whatever the outcome and prints how many matrix jobs it found. On a green
run that is the positive control: a permissions or API problem shows up
immediately as could not list the shard jobs, instead of lying dormant until a
red arrives and the diagnosis turns out to have never been able to speak.

An earlier revision of this body claimed the path could not be exercised without
a failing shard. That was wrong, and the control costs one line.

What this does not do

It does not stop the timeout being hit. That is the eight slowest tests, seven of
them sync start, at 30% of the suite's runtime — #876. And it does not reduce
the queueing that makes a slow shard slower — #877.

This is the third of the three, and the only one about what a person sees when it
goes wrong.