Set Recreate deployment strategy for VPS GitLab webservice/sidekiq

RollingUpdate's default surge kept creating a second pod during every
rollout even with 1 replica - on this CPU-overcommitted single-node
VPS that meant 2 concurrent Ruby boots starving each other, never
converging (load avg hit 39+ on 6 cores). Recreate guarantees only 1
pod exists at a time. No availability cost given minReplicas=maxReplicas=1
already.

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

infrastructure/vps-standby/gitlab/values.yaml

@@ -131,6 +131,15 @@ gitlab:
     # unrelated to GitLab). Less to fork/boot per pod start.
     workerProcesses: 1
     deployment:
+      # Recreate, not the chart default RollingUpdate - with only 1
+      # replica, RollingUpdate still surges an extra pod during every
+      # rollout, and this box can't handle 2 concurrent GitLab Ruby
+      # boots (confirmed live 2026-08-21: load average spiked past 39
+      # on 6 cores, each pod starving the other's boot until both got
+      # liveness-killed - a feedback loop that never converges). No
+      # real availability cost since there's only 1 replica anyway.
+      strategy:
+        type: Recreate
       # Chart defaults (initialDelaySeconds:20, periodSeconds:60,
       # failureThreshold:3 => ~200s grace) aren't enough on this
       # contended box - confirmed live 2026-08-21 the webservice
@@ -219,6 +228,10 @@ gitlab:
   sidekiq:
     minReplicas: 1
     maxReplicas: 1
+    # Recreate, not RollingUpdate - see gitlab.webservice.deployment.
+    # strategy above for why.
+    strategy:
+      type: Recreate
     # Same probe-loosening as webservice.deployment above, same root
     # cause (confirmed live 2026-08-21) - sidekiq's own boot was
     # getting SIGTERM'd mid-`require` by the liveness probe on this