ci: say which test failed, on the run's front page

[VDBBjorn]

Closes #139

What changed

A red build-test used to name the failing test only in the raw job log — on ~2000 tests
that is a scroll to find one line, and the run's front page said nothing at all.

It was worse than that. build/coverage.sh runs under set -e, so the failing dotnet test
aborted the script: no Cobertura.xml was rendered, the coverage summary printed nothing, and
Upload coverage failed on if-no-files-found: error. Two extra red steps, both burying the
one that mattered.

Three changes:

• build/test-summary.py (new) parses .trx and prints a verdict line, a per-assembly
  table, and a <details> block per failure — message in full, stack trimmed to six frames.
  --annotate additionally emits ::error title=…:: workflow commands, which is what puts a
  failure on the Files-changed tab next to the test that produced it. It parses the trx rather
  than console output because the console format is a rendering choice of whichever logger was
  enabled, while the trx is the recorded result. Finding no trx files is not an error: a job
  that died before any test ran has nothing to summarise, and a stack trace from this script
  on top of the real failure helps nobody.
• build/coverage.sh asks for a trx logger, carries the dotnet test exit status to the
  end instead of aborting on it, and tolerates reportgenerator finding nothing to report. It
  still exits non-zero, so the step is still red — it just stops taking the rest of the job
  down with it.
• .github/workflows/ci.yml publishes both summaries to $GITHUB_STEP_SUMMARY with
  if: always() (the pattern mutation.yml already uses), and the examples run now writes a
  trx of its own so its failures land there too.

Verified locally both ways: a passing run renders

🟢 passed — 1487/1490 passed, 0 failed, 3 skipped

with the per-assembly table, and a deliberately failing test renders 🔴 failed, the
<details> block with xUnit's full message and a six-frame stack, and the matching
::error title=…:: line.

Checklist

• dotnet test passes locally (Postgres-backed tests need a running Docker daemon)
• Public API additions or removals are reflected in PublicAPI.Unshipped.txt / PublicAPI.Shipped.txt — no public API touched
• breaking-change label applied if a consumer breaks — nothing breaks; build scripts and workflow only
• CHANGELOG.md not hand-edited; the release workflow drafts it