talmudic-engine: take Debian's libbrotli1 fix for CVE-2026-111497

The Brotli decoder out-of-bounds write (Brotli 1.0.3–1.2.0, fixed
1.2.1) was checked against every deployed image on 2026-10-25. No
decoder is on any attacker-reachable path: Gitea's Go binary has no
Brotli, vav and korban carry no libbrotli and no Python Brotli module,
ingress-nginx has the module unloaded and only ever encodes. Three
dormant copies remain: Gitea's Alpine brotli-libs 1.2.0 (no rebuilt
image on Docker Hub yet), ingress-nginx's brotli-libs 1.1.0, and this
image's libbrotli1 1.0.9-2 from the swipl:9.2.2 base, linked only by
libcurl3-gnutls which nothing here calls.

This one is ours to close. bookworm-security has 1.0.9-2+deb12u1;
the runtime stage now upgrades that single package and nothing else,
so the SWI-Prolog 9.2.2 pin (Construction §1.1) stands.

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

KOHEN.md

@@ -599,9 +599,7 @@ 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 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
+the deployment, waits for 3/3, 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

deploy/docker/Dockerfile.talmudic_engine

@@ -21,6 +21,19 @@ RUN swipl -g "consult('src/main'),halt(0)" -t "halt(1)"
 # === RUNTIME STAGE ===
 FROM --platform=linux/amd64 swipl:9.2.2
 
+# CVE-2026-111497 (Brotli decoder out-of-bounds write, October 2026).
+# The swipl:9.2.2 base carries Debian bookworm's libbrotli1 1.0.9-2,
+# pulled in by libcurl3-gnutls. Nothing in this image decodes Brotli:
+# swipl does not link it, there is no curl binary, and the engine reads
+# JSON from vav over a Unix socket. The copy was dormant, not a path.
+# Debian fixed it in 1.0.9-2+deb12u1 (bookworm-security); take that one
+# package without moving the pinned base. The pin on SWI-Prolog 9.2.2
+# (Construction §1.1) is the point of the base image, so this is
+# --only-upgrade of the one library, not a general upgrade.
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends --only-upgrade libbrotli1 \
+    && rm -rf /var/lib/apt/lists/*
+
 RUN useradd --create-home --shell /bin/bash bikoret
 USER bikoret
 

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; two replicas since 2026-10-25 → 5 each, 10 in all.
-  POOL_SIZE: "5"
+  # single replica.
+  POOL_SIZE: "10"

deploy/k8s/deployment.yaml

@@ -18,25 +18,18 @@ metadata:
     app.kubernetes.io/name: shorashim
     app.kubernetes.io/version: "0.1.0"
 spec:
-  # Two replicas (2026-10-25). A pod that is not ready took every caller
-  # behind the gate dark, and every rollout left a five-minute 503 in
-  # the watchdog log; with two pods and a surge rollout the Service keeps
-  # one Ready pod throughout. One node: this covers rollouts and pod
-  # crashes, not the node. The node has 1700m CPU allocatable and 1470m
-  # was requested (tablet 31, 2026-10-04: a surge pod at 450m hung
-  # Pending), so the requests below are sized to what the pod USES
-  # (vav 20m, sidecars 2m, measured) with headroom — 200m per pod, 400m
-  # for two — not to the old 450m. Limits are unchanged. Each pod reads
-  # the day's manna from the manna-pvc volume and is Ready without the
-  # kohen as long as today's portion was written; the database pool is
-  # 5 per pod (POOL_SIZE in the ConfigMap), 10 in all, under the
-  # hobbyist tier's ceiling.
-  replicas: 2
+  replicas: 1
+  # One replica on one node with no room to surge. The default
+  # (maxSurge 25% → 1 extra pod) asks for 450m CPU the node does not
+  # have beside the running pod, and the rollout hangs Pending while the
+  # old image keeps serving (tablet 31, 2026-10-04). Replace in place.
+  # The new pod reads the day's manna from the manna-pvc volume; it is
+  # Ready again without the kohen, as long as today's portion was written.
   strategy:
     type: RollingUpdate
     rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 0
+      maxSurge: 0
+      maxUnavailable: 1
   selector:
     matchLabels:
       app.kubernetes.io/name: shorashim
@@ -244,7 +237,7 @@ spec:
           resources:
             requests:
               memory: "256Mi"
-              cpu: "120m"
+              cpu: "250m"
             limits:
               memory: "1Gi"
               cpu: "1000m"
@@ -300,8 +293,8 @@ spec:
               mountPath: /tmp
           resources:
             requests:
-              memory: "64Mi"
-              cpu: "40m"
+              memory: "128Mi"
+              cpu: "100m"
             limits:
               memory: "512Mi"
               cpu: "500m"
@@ -325,8 +318,8 @@ spec:
               mountPath: /tmp
           resources:
             requests:
-              memory: "64Mi"
-              cpu: "40m"
+              memory: "128Mi"
+              cpu: "100m"
             limits:
               memory: "512Mi"
               cpu: "500m"