Sync the self-hosting stack

kubernetes/04-api.yaml

@@ -14,21 +14,13 @@ spec:
     matchLabels:
       app.kubernetes.io/name: jarvis
       app.kubernetes.io/component: api
-  # RECREATED, FOR api 1.0.0 ONLY — the release that crosses from the TypeScript images. A rolling
-  # update would keep a TypeScript pod and a .NET pod serving side by side behind one Service, and
-  # their realtime protocols differ under /socket.io/ (Socket.IO against SignalR): every old pod stops
-  # before the first new one starts, a gap of about thirty seconds, once. The next release puts the
-  # rolling update back:
-  #
-  #   type: RollingUpdate
-  #   rollingUpdate:
-  #     maxUnavailable: 0   # never fewer pods than are being served now
-  #     maxSurge: 1
-  #
-  # With `kubectl apply` or Argo's default client-side apply this switches both ways. Under
-  # server-side apply, a field manager that owns `rollingUpdate` makes the API server refuse it.
   strategy:
-    type: Recreate
+    type: RollingUpdate
+    rollingUpdate:
+      # Never fewer pods than are being served now. A run holds its conversation through a unique
+      # index, so a surge pod cannot double-answer anything.
+      maxUnavailable: 0
+      maxSurge: 1
   template:
     metadata:
       labels:
@@ -156,14 +148,11 @@ spec:
               # `Files/PdfTextWorker.cs`) that is killed past its own limits, so a hostile file costs
               # that process and not this one.
               #
-              # MEASURED on this image, in a cgroup like this pod's (lot 11 P, proof 2j): every upload
-              # slot of two pods busy with a 10 MB, 500-page PDF — the most pages the worker reads —
-              # peaked at 619 MiB and 740 MiB of `memory.current`, the API and its workers together,
-              # from 446 and 496 MiB before. The TypeScript image sized this limit: Prisma's JSON
-              # protocol copied an upload's bytes several times over (~1.1 GiB for three at once)
-              # and a PDF worker's buffers could reach ~500 MB, ~2.75 GiB with every holder full.
-              # None of that is in this process; the 3Gi limit stands until it is lowered on purpose
-              # (docs/dotnet/PLAN.md, "Left to Antoine after lot 11"). The request is what the
+              # MEASURED on this image, in a cgroup like this pod's: every upload slot of two pods
+              # busy with a 10 MB, 500-page PDF — the most pages the worker reads — peaked at 619 MiB
+              # and 740 MiB of `memory.current`, the API and its workers together, from 446 and
+              # 496 MiB before. The 3Gi limit was sized generously and sits well above that
+              # 0.6–0.75 GiB peak; it stands until it is lowered on purpose. The request is what the
               # scheduler sets aside for an ordinary day, not for the worst minute.
               memory: 1Gi
             limits: