Sync the self-hosting stack

kubernetes/05-web.yaml

@@ -1,6 +1,16 @@
 apiVersion: apps/v1
 kind: Deployment
 metadata:
+  # Beside the api, in the same wave, and NOT because it is independent of it — measured on a real
+  # cluster, this pod's `/readyz` is nginx proxying the api's `/api/health/live`, so it answers 502
+  # and stays unready for as long as there is no api behind it.
+  #
+  # The same wave is still right. Argo waits for a wave as a whole, so the api coming up is what
+  # makes this ready and there is nothing for a later wave to add; putting it earlier would only
+  # mean it sat unready for longer. What it does mean is that a stuck api presents as TWO unhealthy
+  # Deployments rather than one, and the api is the one to look at.
+  annotations:
+    argocd.argoproj.io/sync-wave: "1"
   name: jarvis-web
   namespace: jarvis
 spec:
@@ -112,6 +122,9 @@ spec:
 apiVersion: v1
 kind: Service
 metadata:
+  # With the Deployment it belongs to.
+  annotations:
+    argocd.argoproj.io/sync-wave: "1"
   name: jarvis-web
   namespace: jarvis
 spec:
@@ -134,6 +147,9 @@ spec:
 apiVersion: autoscaling/v2
 kind: HorizontalPodAutoscaler
 metadata:
+  # With the Deployment it belongs to.
+  annotations:
+    argocd.argoproj.io/sync-wave: "1"
   name: jarvis-web
   namespace: jarvis
 spec: