CI-CD: cash in the delta rule - 64 over 22, the first run holding all three rounds

All three parallel rounds have now merged, and this page had three deltas
on it (+2 rss-bridge, +4 realm hostnames, +2 MTA-STS) each of which
deferred the running total to "the first run on main that holds all of
them". The MTA-STS round was the last of the three, so its own run IS that
run: 64 assertions over 22 charts, 0 failed, stalwart contributing 4.

Replaces my own 60/22, which was measured before #122 landed and was
already the second figure this paragraph had to correct.

The intermediate numbers are kept legible on purpose rather than tidied
away - 58/22, 60/21, 60/22 were each correct for the substructure they were
read on, and none of them is a total. And 62 + 2 = 64 is named as a CHECK
rather than as the source: the figure above was read from a run, and the
arithmetic only agrees because nothing else moved in between. A round that
changes an existing chart's routes instead of adding a chart would not add
up that way at all, which is the whole reason the convention says to read
the total rather than sum the deltas.

CI-CD.md

@@ -172,7 +172,9 @@ The fail path was exercised rather than assumed: a Service renamed in the route,
 
 **The MTA-STS routes of Gitea #123 add `2`**, the third of the three parallel rounds and the one that shows what this figure means from now on: `stalwart` goes from **2** assertions to **4** — one `parentRefs` and one `backendRefs` assertion for its new MTA-STS route — and **the chart count does not move at all.** Every earlier entry in this history grew because a chart *joined* the list; this is the first that grew because a chart already in it gained an **object**. That is the ordinary shape of the next one too, now the sweep is done.
 
-Measured under the same delta rule, and worth stating precisely because three branches were in flight at once: **`60` assertions over `22` charts**, read on a branch that **did** contain `rss-bridge` (it had merged by then) and did **not** contain the realm hostnames of #122. So `58 + 2`. Against the `62/22` above — which is `rss-bridge` plus #122 and not this round — the three deltas are `+2`, `+4` and `+2`, and the total once all three have landed is to be **read off the first run on `main` that holds all of them**, not added up here.
+**And this is where the delta rule gets cashed in: `64` assertions over `22` charts, `0` failed.** The three rounds ran in parallel on branches that contained none of each other, so each published a delta — `+2` for `rss-bridge`, `+4` for the realm hostnames, `+2` here — and each deferred the running total to *"the first run on `main` that holds all of them"*. This round was the last of the three to merge, so its own run **is** that run: rebased onto a `main` already carrying the other two, `ci/run-httproute-match-test.sh` reads `64` over `22`, with `stalwart` contributing `4`.
+
+Worth keeping the intermediate figures legible rather than tidying them away, because each was correct for what it was measured on and none of them is the total: `58/22` on the `rss-bridge` branch, `60/21` on the realm-hostname branch, `60/22` on this one before #122 landed. `62 + 2 = 64` happens to agree, and that agreement is a **check, not the source** — the number above was read, and the arithmetic is only reassuring because nothing else moved in between. Where a round changes an existing chart's routes rather than adding a chart, the deltas would not add up like that at all.
 
 And it only counts because the overlay was extended to enter the new shape (`ci/httproute/stalwart.yaml` carries an entry with a `clusterIssuer`, one without, and one host on a subdomain). An overlay left alone would have added a route this test never rendered — the anti-vacuum rule biting on a **second** object inside a chart that already passes, which is a gap no per-chart "has an overlay" check can see.