docs(ci): three runs, and the load explanation does not hold

ci/keycloak/test-values.yaml

@@ -30,24 +30,26 @@
 #      first over the database would fail the run. Measured in Gitea PR #87:
 #      71.8s from `helm install` to both Ready, 0 restarts - three runs, all
 #      three 72s and 0 restarts.
-#      THE FOURTH RUN WAS NOT THAT, AND THE NUMBER IS RECORDED RATHER THAN
-#      SMOOTHED (Gitea PR #92, run 585): 101s, and ONE restart on one of the two
-#      pods. The same run was measurably slower everywhere - the UNCHANGED
-#      postgres fixture took 51.5s to roll out instead of 27.4s - so the runner
-#      was about half as fast, and this chart's first install is where that
-#      shows: two replicas serialize on the Liquibase migration lock, which is
-#      the whole reason settings.env budgets 900s. WHAT THE RESTART WAS HAS NOT
-#      BEEN ESTABLISHED, because the harness dumps container logs only when a
-#      run FAILS, and this one passed - which is the lasting finding here: the
-#      green path cannot explain a restart it reports.
-#      WHAT DID SETTLE THE QUESTION WAS A SECOND RUN OF THE IDENTICAL MANIFESTS
-#      (run 590): 82s, 0 restarts, postgres back to 23.4s. Same chart, same
-#      theme mount, fast runner - so the restart belongs to the environment and
-#      not to the pod spec. Keep both numbers: "0 restarts" is an observation
-#      about four runs on a runner of varying speed, not an invariant of the
-#      chart, and a first install that serializes two replicas on a schema
-#      migration lock is exactly the shape that gets slower-than-linearly worse
-#      on a loaded machine.
+#      THE NEXT THREE RUNS WERE NOT THAT, AND THE NUMBERS ARE RECORDED RATHER
+#      THAN SMOOTHED (Gitea PR #92, same manifests in all three - the two later
+#      commits change only comments):
+#          run 585: 101s, ONE restart on one of the two pods
+#          run 590:  82s, 0 restarts
+#          run 593: 191s, 0 restarts
+#      So the restart is NOT caused by the pod spec: the fastest and the slowest
+#      run both had none, and the run that had one sat between them. The first
+#      explanation that offered itself does not survive the third run either -
+#      run 585 was slower everywhere (the UNCHANGED postgres fixture took 51.5s
+#      instead of 27.4s), but run 593 was slower still and restarted nothing, so
+#      "a loaded runner trips the first install" is not what was measured.
+#      WHAT THE RESTART WAS HAS NOT BEEN ESTABLISHED, and that is the lasting
+#      finding: the harness dumps container logs only when a run FAILS
+#      (diagnose() hangs off the EXIT trap behind "RC -ne 0"), and all three runs
+#      passed - A GREEN RUN CANNOT EXPLAIN A RESTART IT REPORTS. Whoever next
+#      needs that answer has to make the final-state step print the restart
+#      reasons when any counter is above zero.
+#      Read "0 restarts" accordingly: an observation about six runs on a runner
+#      of varying speed, not an invariant of this chart.
 #   5. A MOUNTED LOGIN THEME SURVIVES ALL OF THAT (Gitea #88) - the full
 #      argument sits at keycloak.extraVolumes further down, including what it
 #      still does not prove.