test(ci): restore the theme mount - the A/B shows the restart is pre-existing

ci/keycloak/test-values.yaml

@@ -30,32 +30,39 @@
 #      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 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
-#          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
+#      THAT WAS LUCK, OR A FAST WEEK, AND NOT AN INVARIANT - which took an A/B
+#      inside Gitea PR #92 to establish, because the first five runs there made
+#      it look like the new theme mount had destabilized the start:
+#          WITH the theme mount    (spec of #88)
+#              run 585: 101s, ONE restart on one pod
+#              run 590:  82s, 0
+#              run 593: 191s, 0
+#              run 595: 101s, ONE
+#              run 597: 111s, ONE          -> 3 of 5
+#          WITHOUT it (the same branch, the pair commented out; pod template
+#          hash 5844db56b6, i.e. BYTE-IDENTICAL to the spec PR #87 measured)
+#              run 598:  81s, 0
+#              run 599: 171s, ONE          -> 1 of 2
+#      So the restart happens WITHOUT the mount as well, and #88 is not its
+#      cause. It is pre-existing, intermittent behaviour of THIS chart's first
+#      install: always exactly one restart on one pod, 35-80s before that pod
+#      reports Ready. It does not track the runner's speed either - the fastest
+#      (81s) and the slowest (191s) run of the whole series restarted nothing.
+#      WHAT THE RESTART IS HAS NOT BEEN ESTABLISHED, and that is the finding
+#      worth keeping: the harness dumps container logs only when a run FAILS
+#      (diagnose() hangs off the EXIT trap behind "RC -ne 0") and all seven runs
+#      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.
+#      counter is above zero; that is a change to ci/run-install-test.sh with a
+#      CI-CD wiki obligation of its own, and it was deliberately NOT made inside
+#      #88. A first install that serializes two replicas on the Liquibase
+#      migration lock is a plausible place for it - stated as the hypothesis it
+#      is, because nothing here measured it.
+#      THE METHOD IS THE PART TO REUSE: a counter that moved in the same round
+#      as a change is not evidence against the change until the control case has
+#      run on the SAME machine. Three clean runs two days earlier were not that
+#      control, and treating them as one would have cost this PR its conclusion
+#      in both directions.
 #   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.
@@ -181,28 +188,20 @@ keycloak:
   # the subpath hides nothing is a property of the mount path rather than a
   # measurement - and the kcLogoIdP line needs a browser plus a realm setting,
   # neither of which exists in CI.
-  # TEMPORARILY DISABLED FOR AN A/B MEASUREMENT, RESTORED BEFORE THIS PR IS
-  # MERGED. Three of five runs with the mount restarted one pod once, while the
-  # three runs of PR #87 without it restarted none - too close to be dismissed
-  # and not establishable from a green log. So the control case is measured on
-  # the SAME runner: this commit is the chart's pre-#88 fixture, the next one
-  # puts the mount back with the numbers written down.
-  # Control runs so far: 598 -> 81s, 0 restarts (pod template hash 5844db56b6,
-  # i.e. byte-identical to the spec PR #87 measured).
-  # If this commit is what
-  # reaches main, the restore was lost and the install-test no longer walks the
-  # path #88 added.
-  # extraVolumes:
-  #   - name: login-theme
-  #     configMap:
-  #       name: ci-keycloak-theme
-  #       items:
-  #         - key: theme.properties
-  #           path: login/theme.properties
-  # extraVolumeMounts:
-  #   - name: login-theme
-  #     mountPath: /opt/keycloak/themes/ci-theme
-  #     readOnly: true
+  extraVolumes:
+    - name: login-theme
+      configMap:
+        name: ci-keycloak-theme
+        items:
+          - key: theme.properties
+            path: login/theme.properties
+  extraVolumeMounts:
+    - name: login-theme
+      # THE SUBPATH, AND THE WHOLE POINT OF THE EXAMPLE: a volume on
+      # /opt/keycloak/themes would hide the image's own three themes and break
+      # the login page while the pod stayed Ready.
+      mountPath: /opt/keycloak/themes/ci-theme
+      readOnly: true
 
 ingress:
   # Left ON although no ingress controller answers in CI: the point is that