docs(ci): record the keycloak install-test run that was slower and restarted once

ci/keycloak/test-values.yaml

@@ -28,7 +28,20 @@
 #      rollout is complete only when BOTH pods are Ready, so a second replica
 #      that crashed, deadlocked on the schema migration lock or fought the
 #      first over the database would fail the run. Measured in Gitea PR #87:
-#      71.8s from `helm install` to both Ready, 0 restarts.
+#      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. So treat "0 restarts" as an observation
+#      from three fast runs rather than as an invariant of the chart, and if a
+#      run ever needs the reason, the harness has to print it on the green path
+#      too.
 #   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.