Set the chart's placeholder version to 0.37.0

replicas and strategy: Recreate were the chart's only guard against the
archiver, notifier and migration races; v0.36.0 closed all three with
advisory locks and a conflict-resolving incident insert, which made
that guard redundant rather than load-bearing. Expose replicaCount
(new, no values.yaml key existed before) defaulting to 2, and switch
to strategy: RollingUpdate with no explicit maxUnavailable/maxSurge --
the 25%/25% default rounds to 0/1 at replicaCount: 2, which is already
zero-downtime.

The chart does not gate this on image.tag, so pointing it at a
pre-v0.36.0 image with the new default is a foot-gun by omission --
noted in both the values.yaml comment and the deployment.yaml comment,
not guarded in code, same as the chart does for every other
version-coupled assumption today.

Co-authored-by: Claude <noreply@anthropic.com>

charts/terdut-server/Chart.yaml

@@ -15,5 +15,5 @@ type: application
 # appVersion and image.tag in values.yaml no longer agree, and that is not an oversight:
 # image.tag stays "latest", which is what a local install actually pulls. appVersion is
 # metadata and drives nothing.
-version: 0.36.0
+version: 0.37.0
-appVersion: "v0.36.0"
+appVersion: "v0.37.0"

charts/terdut-server/templates/deployment.yaml

@@ -6,20 +6,19 @@ metadata:
   labels:
     {{- include "terdut-server.labels" . | nindent 4 }}
 spec:
-  replicas: 1
+  replicas: {{ .Values.replicaCount }}
   selector:
     matchLabels:
       {{- include "terdut-server.selectorLabels" . | nindent 6 }}
-  # Recreate, not RollingUpdate, even though the PVC that forced it is gone:
+  # RollingUpdate, not Recreate: the sweeper, notifier and migration runner
-  # the sweeper, notifier and migration runner take a Postgres advisory lock
+  # each take a Postgres advisory lock around their own pass, and new-incident
-  # each, and new-incident creation on the first webhook for a brand-new
+  # creation on the first webhook for a brand-new groupKey resolves its own
-  # groupKey resolves its own insert conflict — so two replicas overlapping
+  # insert conflict -- so two replicas overlapping during a rollout no longer
-  # during a rollout no longer double-page, race a migration, or drop a
+  # double-page, race a migration, or drop a webhook payload (v0.36.0). No
-  # webhook payload. Nothing left here actually requires Recreate anymore;
+  # explicit maxUnavailable/maxSurge: the 25%/25% default rounds to 0/1 at
-  # it stays the default pending a deliberate decision to raise replicas
+  # replicaCount: 2, which is zero-downtime already.
-  # above 1 and move to RollingUpdate.
   strategy:
-    type: Recreate
+    type: RollingUpdate
   template:
     metadata:
       labels:

charts/terdut-server/values.yaml

@@ -1,3 +1,10 @@
+# Safe above 1 since v0.36.0: the sweeper, notifier and migration runner each
+# take a Postgres advisory lock around their own pass, and a webhook that
+# loses the race to open a brand-new incident attaches to the winner's row
+# instead of dropping its payload. An image older than v0.36.0 does not have
+# these guards -- do not raise this against one.
+replicaCount: 2
+
 networking:
   hostname: "terdut.example.com"
   servicePort: 8080