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>

KOHEN.md

@@ -599,7 +599,9 @@ aligned, not that the output is true. Read `limits` in the response.
 ### Rolling out — *Nesi'at haMishkan*
 
 `scripts/shorashim-rollout` (also installed at `~/.local/bin/`) restarts
-the deployment, waits for 3/3, and takes two consecutive 200s from
+the deployment, waits for both pods (two replicas since 2026-10-25,
+surge rollout: one pod stays Ready throughout, so a rollout no longer
+shows in the watchdog log), and takes two consecutive 200s from
 `/kodesh/health` before reporting — a rollout is not done at 3/3 (NLB
 re-admission lag). A new image must already be pushed as `:latest`. If
 the day's manna has not been written, the new pod hangs at 2/3 until it