keycloak: the third install-test run disproves the load explanation

keycloak.md

@@ -401,7 +401,7 @@ This chart renders **no** NetworkPolicy. If one is ever added, it has to allow 7
 
 **The install-test runs with two replicas**, and the rollout is complete only when **both** pods are Ready — so a second replica that cannot start, deadlocks on the schema migration lock or fights the first over the database fails the run. Measured in Gitea PR #87: **71.8 seconds** from `helm install` to both pods Ready, 0 restarts — three runs, all three the same.
 
-**Read that as an observation and not as an invariant.** A fourth run (PR #92) took **101s and restarted one of the two pods once**, and the same run was slower everywhere — the *unchanged* postgres fixture needed 51.5s instead of 27.4s. A fifth run of the identical manifests was back at 82s with 0 restarts. So the restart belongs to the runner rather than to the pod spec, and the shape is worth remembering: a first install that serializes two replicas on the Liquibase migration lock degrades more than linearly on a loaded machine. **What the restart actually was could not be established, because the harness dumps container logs only when a run fails** — a green run cannot explain a restart it reports.
+**Read that as an observation and not as an invariant.** Three further runs of identical manifests in PR #92 measured **101s with one restart**, **82s with none**, and **191s with none**. The fastest and the slowest run restarted nothing and the middle one did, so it is not the pod spec — and it is not simply a loaded runner either, which was the first explanation and did not survive the 191s run. **What the restart was could not be established, because the harness dumps container logs only when a run fails** — a green run cannot explain a restart it reports. Whoever needs that answer has to make the final-state step print the restart reasons when a counter is above zero.
 
 **What that does *not* prove is that `jdbc-ping` found the peer**, and reading it that way is the mistake this paragraph exists to prevent. Readiness reports *this* node's health, so a node that never found its peer is Ready, healthy and alone — and two such nodes are two islands that each believe they are the cluster. The Infinispan view has to be read out of the log, which is what step 2 of the first-install checklist is for. So the test rules out the louder half and leaves the quiet half to a human.