fix(ariadne): let the pod finish booting before liveness judges it

The earlier probe fix addressed slow /health responses under load, but the
restarts continued with a different signature: connection refused rather than
timeout, meaning the app was not listening yet. Ariadne runs migrations and
builds its cron schedule before binding, which can outlast what liveness
allows from initialDelaySeconds, so the kubelet kept restarting a pod that
was merely still starting.

Add a startupProbe granting up to five minutes to come up, after which
liveness takes over unchanged. This is the case startupProbe exists for.

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

services/maintenance/apps/ariadne-deployment.yaml

@@ -572,6 +572,19 @@ spec:
           # /health. Three of those in a row and the kubelet kills a container
           # that is working perfectly well. Observed 11 times in 139 minutes,
           # each one dropping triage ticks for the length of a restart.
+          # Startup is the other way this pod gets killed while healthy. It
+          # runs migrations and builds its schedule before it listens, which
+          # can take longer than liveness allows from initialDelaySeconds
+          # alone, and the kubelet then reports "connection refused" and
+          # restarts a pod that was simply still booting. A startupProbe gives
+          # boot up to five minutes and only then hands over to liveness.
+          startupProbe:
+            httpGet:
+              path: /health
+              port: http
+            periodSeconds: 10
+            timeoutSeconds: 5
+            failureThreshold: 30
           livenessProbe:
             httpGet:
               path: /health