manna: the provision falls at the boundary — 00:00Z — and readiness is carried across it

The watchdog's first night (2026-10-21): 503 at 00:00:01Z with
manna_present and esh_tamid failing, recovered 00:05Z. Every night since
the CronJob was applied the site has been dark one to five minutes:
the provision is stale from 00:00:00, the job ran at 00:01, and the
readiness probe (10 s period, default threshold 3) fell in the gap.

Not changed: the rule. A provision is for its day; Friday's double is
the Shabbat's; nothing else crosses the boundary (Shemot 16:19–26,
manna_shabbat_test.exs). Changed: the timing.
- manna-cronjob.yaml: schedule "0 0 * * 0-5" — the manna falls at the
  boundary, not a minute after it.
- deployment.yaml: readinessProbe.failureThreshold 6 — 60 s of failures
  before the Service stops routing. The job writes within seconds of
  00:00; the pod is carried across. A real outage still shows within a
  minute; the watchdog's own threshold is ten.
- KOHEN.md: the night's finding and the new timing.

Both manifests validate (kubectl apply --dry-run=client). Proof: the
watchdog log on the next boundary should show no FAIL at 00:00.

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

deploy/k8s/deployment.yaml

@@ -266,6 +266,13 @@ spec:
               port: 4000
             initialDelaySeconds: 10
             periodSeconds: 10
+            # 60 s of failures before the Service stops routing here (the
+            # default is 30 s). The manna goes stale at 00:00:00 and the
+            # CronJob writes the new day's within seconds; the cushion
+            # carries the pod across that boundary without a 503. A real
+            # outage still shows within a minute, and the watchdog's own
+            # threshold is ten.
+            failureThreshold: 6
 
         # === SHORESH ENGINE ===
         # Not a container. It runs as an Erlang Port inside