ops: prop deployment floor at 2 replicas, surge to 4

A single-pod floor meant any pod restart (rolling deploy mid-run,
OOM kill, node drain) took the whole site down for the boot window.
Bump HPA to minReplicas: 2 / maxReplicas: 4 so the floor is HA and
load surges (LiveView traffic coinciding with the hourly propagation
chain) still get headroom. Combined with the existing rolling-update
strategy (maxSurge: 1, maxUnavailable: 0) this means deploys go
2 -> 3 -> 2 with zero downtime.

k8s/deployment.yaml

@@ -4,9 +4,9 @@ metadata:
   name: prop
   namespace: prop
 spec:
-  # replicas is owned by the HPA in hpa.yaml (currently pinned at 1).
+  # replicas is owned by the HPA in hpa.yaml (floor 2, max 4). Leaving
-  # Leaving it out here so the GitOps reconciler doesn't overwrite
+  # it out here so the GitOps reconciler doesn't overwrite whatever
-  # whatever replica count the autoscaler has settled on.
+  # replica count the autoscaler has settled on.
   minReadySeconds: 5
   strategy:
     type: RollingUpdate

k8s/hpa.yaml

@@ -22,11 +22,13 @@ spec:
     apiVersion: apps/v1
     kind: Deployment
     name: prop
-  # Pinned at 1 pod (min == max). HPA still owns the replica count so
+  # Floor at 2 pods so a single-pod restart never takes the site down,
-  # Flux reconcile stays out of the way; raise both bounds together to
+  # surge up to 4 under load (LiveView burst + hourly propagation
-  # restore autoscaling.
+  # chain). Combined with deployment.yaml's `maxSurge: 1, maxUnavailable: 0`
-  minReplicas: 1
+  # rolling-update strategy, deploys still get an extra pod up before
-  maxReplicas: 1
+  # tearing one down.
+  minReplicas: 2
+  maxReplicas: 4
   metrics:
     - type: Resource
       resource: