CI-CD: the running total both rounds deferred is 62 over 22, measured

The rss-bridge round and the realm-hostname round were measured on branches
that did not contain each other (58/22 and 60/21), so both left the running
total to the first branch holding both. That branch exists now - the
realm-hostname branch with main merged into it - and the figure is 62
assertions over 22 charts, 0 failed, keycloak contributing 8.

Read off ci/run-httproute-match-test.sh rather than added up, which is the
rule both rounds wrote down.

CI-CD.md

@@ -164,7 +164,7 @@ Group 3 took it to `56` assertions over `21` charts. Its 19 come from six charts
 
 **`rss-bridge` finishes the sweep at `58` assertions over `22` charts** — one route, so two assertions. It was the last chart left: 22 charts carried an Ingress template and 21 an HTTPRoute template, and the difference was exactly that one, held back by Gitea #51 rather than by anything about its shape.
 
-**The realm hostnames of Gitea #122 add `4`**, and they are objects rather than a new check: `keycloak`'s share goes from 4 to 8 — one `parentRefs` and one `backendRefs` assertion for each of its two realm routes — plus one "not checked" line each for their backend-less redirect rule (`keycloak: ok (8 assertion(s) held, 2 not checked)`). The #118 prefix/redirect pairing deliberately does **not** fire on them: it is scoped to rules that strip a prefix with a `ReplacePrefixMatch` rewrite, and a realm route strips nothing — it redirects the bare root of a hostname that serves one realm. **The two rounds were measured separately and neither total includes the other**: `58/22` was read on the `rss-bridge` branch and `60/21` on the realm-hostname branch, which did not contain `rss-bridge`. So the **delta** is the figure to trust from either, and the running total is whatever the first run on `main` prints once both are in — read it there rather than adding these up, which is the same rule that produced both numbers.
+**The realm hostnames of Gitea #122 add `4`**, and they are objects rather than a new check: `keycloak`'s share goes from 4 to 8 — one `parentRefs` and one `backendRefs` assertion for each of its two realm routes — plus one "not checked" line each for their backend-less redirect rule (`keycloak: ok (8 assertion(s) held, 2 not checked)`). The #118 prefix/redirect pairing deliberately does **not** fire on them: it is scoped to rules that strip a prefix with a `ReplacePrefixMatch` rewrite, and a realm route strips nothing — it redirects the bare root of a hostname that serves one realm. **The two rounds were measured separately and neither total includes the other**: `58/22` was read on the `rss-bridge` branch and `60/21` on the realm-hostname branch, which did not contain `rss-bridge`. So the **delta** is the figure to trust from either, and and the running total was read off the first branch that held both — the realm-hostname branch with `main` merged into it — rather than added up by hand: **`62` assertions over `22` charts, `0` failed**. `keycloak` contributes `8`, one `parentRefs` and one `backendRefs` assertion for each of its four routes.
 
 **That chart's install-test also went green in the same PR**, after failing on this runner since the move — the event #51 had designated as its own signal, and the reason the chart was deliberately never added to `ci/excluded-charts.txt`. Pod `1/1 Ready` in 22 s, 0 restarts, no `Permission denied` in the job. The chart is ruled out as the cause by measurement rather than by argument: that PR's rendered defaults are **byte-identical** to `origin/main`, so the pod spec that installed is the one that had been failing. The runner is the implicated layer. It reproduced on every run of that branch after the first, so it is not a single fluke, and #51 was closed on that round. The cause, however, was **never identified** — nobody established what changed on the runner, and that issue's diagnostic programme was not executed. A fresh red on this chart is therefore a finding, not a known quirk. See [rss-bridge](rss-bridge).