Loosen VPS GitLab sidekiq liveness probe further (~17min grace)

3 consecutive attempts with the first loosening (~8min grace) all made
genuine progress (booted, started listening on queues) but never got
to open the health-check port before being killed - box's sustained
background load (gitea, restic, barman, k3s - unrelated to GitLab) is
apparently enough to starve that specific thread. More patience, not
a different fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

infrastructure/vps-standby/gitlab/values.yaml

@@ -237,12 +237,22 @@ gitlab:
     # getting SIGTERM'd mid-`require` by the liveness probe on this
     # CPU-contended box, every ~90-150s, resetting to zero each time
     # and never actually finishing.
+    # Loosened further 2026-08-21: even with the first pass above, 3
+    # consecutive attempts all reached "Booting Sidekiq" (the real
+    # engine actually starts, confirmed via "Listening on queues" in
+    # logs) but never opened the health-check port (3808) within the
+    # ~8min grace window - the box's ambient background load (gitea,
+    # restic backup, barman, k3s itself - all unrelated to GitLab, load
+    # average sustained 35-55 on 6 cores) is apparently severe enough to
+    # starve that specific thread's CPU scheduling even after the main
+    # process is otherwise up. Genuine forward progress each time, not
+    # a hard hang, so more patience rather than a code fix.
     livenessProbe:
-      initialDelaySeconds: 60
+      initialDelaySeconds: 120
       periodSeconds: 30
       timeoutSeconds: 30
       successThreshold: 1
-      failureThreshold: 15
+      failureThreshold: 30
     resources:
       requests:
         cpu: 25m