docs(ci): the whole restart series, intermittent on an unchanged spec

ci/keycloak/test-values.yaml

@@ -30,26 +30,32 @@
 #      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 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):
+#      THE RUNS OF PR #92 WERE NOT THAT, AND THE NUMBERS ARE RECORDED RATHER
+#      THAN SMOOTHED. Identical pod spec in all four - the later commits on that
+#      branch change comments only:
 #          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.
+#          run 595: 101s, ONE restart on one of the two pods
+#      Three things that are worth more than the average: the restart is
+#      INTERMITTENT on an unchanged spec (2 of 4), it is always exactly ONE on
+#      ONE pod, about 35s before that pod reports Ready - and it does not track
+#      the runner's speed, which was the first explanation and does not hold:
+#      the FASTEST (82s) and the SLOWEST (191s) run restarted nothing, and the
+#      two that restarted were both 101s.
+#      WHAT THE RESTART IS HAS NOT BEEN ESTABLISHED, and that is the lasting
+#      finding of the series: the harness dumps container logs only when a run
+#      FAILS (diagnose() hangs off the EXIT trap behind "RC -ne 0") and all four
+#      passed - A GREEN RUN CANNOT EXPLAIN A RESTART IT REPORTS. Answering it
+#      means making the final-state step print the restart reasons whenever a
+#      counter is above zero; that is a change to ci/run-install-test.sh and it
+#      was deliberately NOT made inside #88.
+#      The counting stops here on purpose - every further commit adds a run, and
+#      a comment that chases the tally is wrong at the next push. What is worth
+#      carrying is the shape, not the tally: "0 restarts" is an observation, not
+#      an invariant of this chart, and a first install that serializes two
+#      replicas on a schema migration lock is a plausible place for one - which
+#      is a hypothesis, stated as one, because nothing here measured it.
 #   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.