Default TerdutServer.spec.replicas to 2 and switch to RollingUpdate

Mirrors charts/terdut-server's own deployment.yaml change: v0.36.0 put
the sweeper, the notifier and the migration runner each behind a
Postgres advisory lock, and gave incident creation its own conflict
resolution, so the Recreate strategy and replicas-stays-at-1 guidance
this controller carried (explicitly tracking that chart's comment)
are no longer load-bearing.

spec.replicas' +kubebuilder:default moves 1 -> 2 (config/crd/bases and
the chart's CRD template regenerated via controller-gen and
kubebuilder's helm plugin respectively, then hand-verified identical
to the generator's own output rather than trusting a bulk regen --
the plugin's --output-dir charts writes a fresh charts/chart scaffold
rather than updating charts/terdut-operator in place, so only the
diff was taken, not the whole tree). terdutserver_deployment.go's
same-value fallback (reachable only for a TerdutServer stored before
this default existed) moves with it, and its Strategy changes from
Recreate to RollingUpdate with no explicit maxUnavailable/maxSurge --
the 25%/25% default rounds to 0/1 at replicas: 2, already
zero-downtime.

DESIGN.md's three places asserting multi-replica isn't a supported
topology (the illustrative spec.replicas YAML, spec.pod.affinity's
rationale, and the HPA deferred-feature note) are corrected to match;
the HPA note now gives its own standing reason (no scaling metric or
bounds decided yet) rather than a contradiction that no longer holds.

The chart's optional terdutServer.replicas sample value moves 1 -> 2
alongside it. image.tag must be v0.36.0 or newer for any of this to
hold -- stated in both the CRD field's doc comment and the chart
value's comment, not enforced in code, same stance the chart takes on
every other version-coupled assumption.

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

api/v1alpha1/terdutserver_types.go

@@ -229,11 +229,11 @@ type PodSpec struct {
 	Tolerations []corev1.Toleration `json:"tolerations,omitempty"`
 
 	// affinity covers node affinity, pod affinity and pod anti-affinity in
-	// one field -- unlike a multi-replica-aware operator, this one never
-	// generates a default anti-affinity itself (replicas above 1 isn't a
-	// supported topology, see TerdutServerSpec.Replicas's own doc comment),
-	// so this is pure user-supplied passthrough, not a toggle-plus-generated-
-	// default.
+	// one field -- even though replicas now defaults to 2 (see
+	// TerdutServerSpec.Replicas's own doc comment), this operator still
+	// never generates a default anti-affinity of its own the way a
+	// multi-replica-aware operator typically would, so this stays pure
+	// user-supplied passthrough, not a toggle-plus-generated-default.
 	// +optional
 	Affinity *corev1.Affinity `json:"affinity,omitempty"`
 
@@ -301,10 +301,14 @@ type TerdutServerSpec struct {
 	// +required
 	Image ImageSpec `json:"image"`
 
-	// replicas. terdut-server is not horizontally-scale-tested; keep this
-	// at its default of 1 unless you've verified otherwise -- the sweeper
-	// and the notifier are unsynchronised singletons.
-	// +kubebuilder:default=1
+	// replicas. Defaults to 2: terdut-server v0.36.0 put the sweeper, the
+	// notifier and the migration runner each behind a Postgres advisory
+	// lock, and gave incident creation its own conflict resolution, so
+	// more than one replica no longer double-pages, races a migration, or
+	// drops a webhook payload. image.tag must be v0.36.0 or newer for
+	// that to hold -- an older terdut-server has none of these guards,
+	// and this field does not check the tag for you.
+	// +kubebuilder:default=2
 	// +optional
 	Replicas int32 `json:"replicas,omitempty"`