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>

DESIGN.md

@@ -153,7 +153,7 @@ spec:
   image:
     repository: git.ryuvia.com/niklas/terdut-server
     tag: v0.9.3
-  replicas: 1                      # terdut-server is not horizontally-scale-tested; keep the field, default 1
+  replicas: 2                      # default since terdut-server v0.36.0's advisory locks; see TerdutServerSpec.Replicas
   networking:
     hostname: terdut.example.com
     servicePort: 8080
@@ -244,10 +244,10 @@ no custom wrapper buys anything for any of these, matching how
 CloudNativePG and the Zalando postgres-operator both expose the same
 knobs. `affinity` is pure user-supplied passthrough, not a
 toggle-plus-generated-default the way a multi-replica-aware operator's
-pod anti-affinity typically is: this operator never auto-generates
-affinity of its own, since `replicas` above 1 isn't a supported topology
-(the sweeper/notifier singleton constraint, §4.1's own illustrative YAML
-comment). `spec.pod.disruptionBudget` is the one field here that isn't a
+pod anti-affinity typically is: even though `replicas` now defaults to 2
+(terdut-server v0.36.0's advisory locks made that safe, §4.1's own
+illustrative YAML comment), this operator still never auto-generates
+affinity of its own. `spec.pod.disruptionBudget` is the one field here that isn't a
 straight PodTemplateSpec knob — when set, the controller reconciles a
 `PodDisruptionBudget` selecting this `TerdutServer`'s pods; clearing it
 deletes any it previously created (§7). `minAvailable`/`maxUnavailable`
@@ -832,10 +832,12 @@ what it was, a separate install, until someone deletes it.
 - Automatic Deployment restart on upstream Postgres credential rotation.
 - `spec.pod.priorityClassName`, pod-label passthrough beyond
   `spec.pod.annotations`, and a HorizontalPodAutoscaler for `TerdutServer`
-  — all considered alongside §4.1's `spec.pod` and explicitly left out of
-  that round: an HPA in particular would actively contradict
-  `spec.replicas`'s own stance that this operator doesn't support more
-  than one replica (the sweeper/notifier singleton constraint).
+  — all considered alongside §4.1's `spec.pod` and left out of that round.
+  An HPA no longer contradicts anything now that `spec.replicas` defaults
+  to 2 (terdut-server v0.36.0's advisory locks), but it is still a
+  separate, not-yet-made decision: a fixed replica count has no scaling
+  metric, min/max bounds, or cooldown behaviour to get right, and nobody
+  has asked for it yet.
 - Admission webhooks / CEL-only validation limits (e.g. verifying a
   `teamRef` exists at admission time rather than surfacing it as a status
   condition after the fact).