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>

internal/controller/terdutserver_deployment.go

@@ -37,17 +37,27 @@ func (r *TerdutServerReconciler) reconcileDeployment(
 	_, err := controllerutil.CreateOrUpdate(ctx, r.Client, deploy, func() error {
 		replicas := srv.Spec.Replicas
 		if replicas == 0 {
-			replicas = 1
+			// Only reachable for a TerdutServer stored before the
+			// +kubebuilder:default=2 marker existed -- the API server's own
+			// CRD defaulting fills this in for anything created or updated
+			// through it, so a fresh zero value here means a pre-existing
+			// object that predates the default, not a deliberate "none"
+			// (there is no way to request zero replicas).
+			replicas = 2
 		}
 		labels := labelsFor(srv)
 
 		deploy.Spec.Replicas = &replicas
 		deploy.Spec.Selector = &metav1.LabelSelector{MatchLabels: labels}
-		// Recreate, not RollingUpdate: the sweeper and the notifier are
-		// unsynchronised singletons inside terdut-server, and two replicas
-		// overlapping during a rollout would both page for the same
-		// incident (matches the chart's own deployment.yaml comment).
-		deploy.Spec.Strategy = appsv1.DeploymentStrategy{Type: appsv1.RecreateDeploymentStrategyType}
+		// RollingUpdate, not Recreate: 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 two replicas overlapping during a rollout no longer
+		// double-page, race a migration, or drop a webhook payload (matches
+		// the chart's own deployment.yaml comment). No explicit
+		// maxUnavailable/maxSurge: left at the 25%/25% default, which rounds
+		// to 0/1 at the default replicas: 2 -- already zero-downtime.
+		deploy.Spec.Strategy = appsv1.DeploymentStrategy{Type: appsv1.RollingUpdateDeploymentStrategyType}
 		pod := srv.Spec.Pod
 		deploy.Spec.Template = corev1.PodTemplateSpec{
 			// pod.Annotations is assigned directly, not merged -- nothing