deploy: two replicas, surge rollout, requests sized to use

A pod that is not ready took every caller behind the gate dark, and
every rollout this week left a five-minute 503 in the watchdog log.
Two replicas with maxSurge 1 / maxUnavailable 0 keep one Ready pod
through a rollout or a crash. One node: this covers rollouts and pod
failures, not the node.

The node has 1700m CPU allocatable with 1470m requested; a second pod
at the old 450m request could not schedule (tablet 31 saw the surge
pod hang Pending). The pod USES 22m (vav 20m, sidecars 2m, measured),
so requests move to what is used with headroom: vav 120m/256Mi,
sidecars 40m/64Mi — 200m per pod, 400m for two, less than the one pod
asked before. Limits unchanged. POOL_SIZE 10 → 5 per pod (10 in all,
under the hobbyist tier's ceiling). KOHEN "Rolling out" updated.

Both manifests validate (kubectl --dry-run=client). Doorpost pin
unchanged. Applying needs the transmitter (or the classifier off).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

deploy/k8s/configmap.yaml

@@ -66,5 +66,5 @@ data:
   # a pool of 20 fills its connection ceiling by itself (2026-10-15:
   # refusals "remaining connection slots are reserved" for 24 h, one
   # pool worker looping, Aiven's monitor refused). Ten is ample for a
-  # single replica.
-  POOL_SIZE: "10"
+  # single replica; two replicas since 2026-10-25 → 5 each, 10 in all.
+  POOL_SIZE: "5"