feat(collector): forecast and ntfy in ping-collector; ThaiWater keeps alerts current at night

Phase 2b/2c of docs/RUST_REWRITE.md. With FORECAST_IN_COLLECTOR=true (shared
.env) ping-collector, after each cycle that brought newer RID or HII readings
and at least hourly: loads the last 336 h (RID + HII mirror fill), fetches the
rain forecast, runs every exported model (rust/forecast), stores
forecast_history and forecast_current, and sends the ntfy notifications.
The Python API then serves forecast_current as /forecast (computing in-process
only when it is older than FORECAST_MAX_AGE_SECONDS) and neither forecasts nor
notifies.

ntfy (collector/src/notify.rs): a port of src/notify.py with the same topics,
texts, hysteresis, capacity guard and notification_state keys, checked word
for word on 751 messages generated by Python (testdata/gen_notify_cases.py).
The change: for stations whose ThaiWater twin is the same sensor, a reading
newer than RID's drives the level alerts (marked as ThaiWater telemetry), and
the feed counts as stale only when neither source has a reading for 3 h. RID
alone lagging is reported once after RID_STALE_ALERT_HOURS (18). This ends the
nightly "gauge feed stale" / "recovered" pairs caused by RID's late reports.

Commands: `forecast [--json] [--save] [--now] [--rain-file]`,
`notify --dry-run`. scripts/forecast_parity.py compares Python and the
collector on the live database (same moment, same rain); locally 48/48 rows
identical. install_collector.sh: models export + that check on every install,
--cutover-forecast (refuses on a failed check) and --rollback-forecast.

Trees are packed into 24-byte nodes: 70 MB peak with all 15 models (was 140).
Forecast values are written to NUMERIC as shortest round-trip text, so they
round as psycopg2's do. DB test schemas get a counter (parallel tests collided
on Windows' coarse clock).

docs/NOTIFICATIONS.md

@@ -22,7 +22,7 @@ seventy-two. In a quiet season a subscriber hears nothing.
 | `ping-<station>-warning` | that gauge crosses warning; back to normal | 4 / 2 |
 | `ping-<station>-danger` | that gauge crosses danger; back below danger | 5 / 3 |
 | `ping-p1-outlook` | model P(warning within 24 h) at P.1 rises through 50 % (clears below 25 %) | 4 / 2 |
-| `ping-status` | gauge feed stale ≥ 3 h; feed recovered | 3 / 2 |
+| `ping-status` | no reading for ≥ 3 h; feed recovered; with the Rust notifier also: RID reports ≥ 18 h behind while ThaiWater is current, and back | 3 / 2 |
 
 Station slugs are the code lowercased without the dot: `p1`, `p103`, `p67`.
 Thresholds are the ones in `src/ml/features.py` (`THRESHOLDS`): P.1 3.70 /
@@ -36,7 +36,21 @@ the public dashboard.
 
 ## How it runs
 
-`src/notify.py` is called once per collection cycle inside the API process
+Since phase 2 of the Rust rewrite the notifier runs in `ping-collector`
+(`rust/collector/src/notify.rs`) when `FORECAST_IN_COLLECTOR=true`, after each
+forecast run. It is a port of `src/notify.py` with the same topics, texts and
+state keys (checked word for word against Python on 751 generated messages),
+so switching between the two sends nothing twice. One difference: the Rust
+notifier 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 `FORECAST_IN_COLLECTOR=false`, `src/notify.py` is called once per collection cycle inside the API process
 (leader only), right after the forecast precompute, so it sees exactly the
 readings and forecasts the dashboard shows. Per-key last-sent state is stored
 in the `notification_state` table of the monitor's own database, so a restart