kiosk: distinguish upstream-egress weather failure from a wedged Chromium

The kiosk froze on a stale night/"Weather unavailable" frame while its local
clock kept ticking — caused by msp001 pod egress/DNS loss (a UDM BGP wipe),
not a wedged browser. Document the live-clock symptom and point at the
fritzlab BGP runbook so the next occurrence is diagnosed in seconds.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

reference/kiosk.md

@@ -37,6 +37,13 @@ fails at pod start doesn't sit on "Weather unavailable" for the full 10m
 that node's Chromium (or the whole node) is wedged, NOT a page bug — the
 display holds the last-good frame; recover by graceful pod restart (and see
 fritzlab `msp001.md` <kiosk> if the node itself is unreachable).
+A **live** clock but "Weather unavailable" + a stale day/night scene (night
+shown in daytime) is the opposite case — NOT Chromium: the pod can't reach
+`api.open-meteo.com`, so `wx()` fails and `SUN` (sunrise/sunset) freezes at
+its last-good values → wrong palette. Root cause is usually msp001 pod
+egress/DNS loss from a UDM BGP wipe (now auto-healed) — see fritzlab
+`msp001.md` <bgp>. Confirm with `kubectl --context msp001 exec -n kiosk
+<pod> -- curl -sm10 https://api.open-meteo.com/v1/forecast?...` from the pod.
 Source repo: `websites/kiosk.vino.network` (clone at `~/code/git/code.fritzlab.net/websites/kiosk.vino.network/`),
 content in `html/`, served from Garage S3 via the standard site-publish flow
 (fritzlab `gitops.md` <static-sites>).