docs(ci): the second run settles it - the keycloak restart was the runner, not the pod spec

ci/keycloak/test-values.yaml

@@ -38,10 +38,16 @@
 #      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
+#      run FAILS, and this one passed - which is the lasting finding here: the
-#      from three fast runs rather than as an invariant of the chart, and if a
+#      green path cannot explain a restart it reports.
-#      run ever needs the reason, the harness has to print it on the green path
+#      WHAT DID SETTLE THE QUESTION WAS A SECOND RUN OF THE IDENTICAL MANIFESTS
-#      too.
+#      (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.
 #   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.