fix(notify): no "gauge feed stale" for RID's nightly pause on a quiet river

ping-status sent "gauge feed stale" around midnight and "feed recovered"
around 07:00 on each of the last three nights (ntfy and, since phase 3, the
Matrix room). RID publishes no hourly report overnight: the 21:00 reading is
the last until the 22:00..06:00 hours arrive together (06:35, 06:55, 07:22 on
2026-10-17/18/19). The ThaiWater overlay was meant to bridge that, but
ThaiWater's copies of the RID gauges come from the same feed with the same
delay (P.1's mirror still has no value for 22:00-00:00 this morning), so it
does not.

Between 21:00 and FEED_NIGHT_UNTIL_HOUR (default 9, 0 = off) the feed of a
quiet river is no longer reported stale; one still without new readings at
09:00 is. While a station is at warning/danger or the P.1 outlook is on, the
3 h rule holds all night. A feed already stale stays stale through the night
(no false "recovered"), and a real recovery is announced at any hour. The
replay of the Python notifier runs with the window off. Docs no longer claim
that ThaiWater keeps the feed current at night.

docs/NOTIFICATIONS.md

@@ -43,11 +43,22 @@ keys (checked word for word on 751 generated messages), so the switch sent
 nothing twice. One difference: it also uses ThaiWater (HII) telemetry. For the stations whose HII twin
 is the same sensor (P.1, P.103, P.20, P.4A, P.67, P.75, P.82, P.84, P.92, and
 P.81 bias-corrected), a reading newer than RID's drives the level alerts; the
-message then says "ThaiWater telemetry; the RID report is not in yet". RID's
-report regularly lags 2-10 h at night, which used to send "gauge feed stale"
-around midnight and "recovered" in the morning. Now the feed is stale only
-when neither source has a reading for 3 h, and RID alone lagging is reported
-once after `RID_STALE_ALERT_HOURS` (18, 0 = off). With `MATRIX_*` set, the
+message then says "ThaiWater telemetry; the RID report is not in yet". The feed
+counts as stale when no source has a reading for 3 h, and RID alone lagging is
+reported once after `RID_STALE_ALERT_HOURS` (18, 0 = off).
+
+**RID's nightly pause.** RID publishes no hourly report overnight: on
+2026-10-17, -18 and -19 the 21:00 reading was the last one until the hours
+22:00-06:00 arrived together between 06:35 and 07:22. ThaiWater's copies of the
+RID gauges come from the same feed and arrive with the same delay (P.1's
+mirror had no value for 22:00-00:00 even the next morning), so they do not
+bridge the night. Without a rule for it, every night sent "gauge feed stale"
+around midnight and "feed recovered" around 07:00. So between 21:00 and
+`FEED_NIGHT_UNTIL_HOUR` (9, 0 = off) a quiet river's feed is not reported
+stale; a feed still without new readings at 09:00 is. While any station is at
+warning or danger, or the P.1 outlook is on, the 3 h rule holds all night:
+then a stalled dashboard matters. A feed that was already stale stays stale
+through the night, and a recovery is announced whenever it happens. With `MATRIX_*` set, the
 same transitions also go to a Matrix room, each once (per station, outlook,
 feed; not the per-topic summaries), with their own `matrix:` state keys.
 
@@ -120,6 +131,7 @@ holds back an alert. Test the pipeline before the domain is live with
 | `PUBLIC_URL` | `https://water.buildfor.life/` | click-through target in messages |
 
 | `RID_STALE_ALERT_HOURS` | `18` | report RID lagging this long while ThaiWater is current (0 = never) |
+| `FEED_NIGHT_UNTIL_HOUR` | `9` | end of the night window from 21:00 in which a quiet river's feed is not reported stale (0 = off) |
 | `MATRIX_HOMESERVER` / `MATRIX_ACCESS_TOKEN` / `MATRIX_ROOM_ID` | *(empty = off)* | the team room (docs/MATRIX_QUICK_START.md) |
 
 Tunables in `src/ml/export.py` (compiled into ping-collector through