feat(weather): long-range outlook view and daily digest

[prorochestvo]

Implements #127: a weather view that answers three questions per day — rain or not, snow or
not, above or below 0 °C — over a 16-day horizon, plus a notification channel for the same
information.

The four decisions this was blocked on

Settled by the owner before any code was written:

1. 16 days now, on the v1/forecast endpoint Beacon already calls, with the 35-day
   ensemble left as a later source swap behind the same table rather than a second parallel
   feature.
2. Thresholds: a rain day is rain_sum ≥ 1 mm, a snow day is snowfall_sum ≥ 1 cm
   (Open-Meteo reports rain in millimetres and snowfall in centimetres — verified against a
   live response), and the freezing axis is three-state: above (min > 0), crossing
   (min ≤ 0 < max), below (max ≤ 0).
3. Notify as well as view, delivered as a once-a-day digest rather than per-flip alerts.
4. Refresh once a day.

What changed

Storage. A new weather_forecast_days table, keyed on
(location_id, provider, forecast_date) and upserted in place. It is deliberately not
weather_observations: the collector sweeps that table by captured_at at 48 hours on
every tick, so a row describing a day two weeks out would be deleted a day and a half after
it was written, with no error anywhere. It is not tiered either — the rows are a bounded
working set of locations × 16, so an *_archive twin would have nothing to hold.
Retention is keyed on forecast_date and keeps one day of slack, because UTC offsets run
from −12 to +14.

Collection. OpenMeteo.ForecastRange issues its own request rather than widening
Forecast. Forecast decodes daily index [0], and that index is today for the morning
summary and for all four daily-metric alert latches; changing what it asks for would put
their meaning at risk of a shift that nothing would report. The second request costs roughly
one weighted API call per location per day against a budget of 10,000. Forecast and its
decoder are byte-for-byte unchanged — the diff on that file is additions only.

WeatherForecastAgent runs beside WeatherAgent and gates on the UTC calendar day, not
on 24 elapsed hours: against an hourly cron the elapsed-time form drifts an hour later every
day and eventually lands after the subscriber's notify hour.

Notification. A new forecast_outlook kind, opt-in like heat and frost rather than
forced. It is the one kind outside the latch model: a day two weeks out changes its mind
several times before it arrives, so a latch per condition would either send every flip or,
with a dead band wide enough to stop that, say nothing at all. Instead the notifier compares
the outlook's signature against a new notify_state column and queues a message only when
it differs, marking the days that moved and naming the ones that cleared. The cursor
advances on every evaluation that had data, which bounds the digest at one message per city
per local day regardless of how often the collector refreshes underneath it.

A day is reported when it brings rain, snow, or a change in the freezing regime.
Reporting every cold day would fill a winter digest with the fact that February is cold.

API and UI. GET /api/v1/me/weather/current gains a days array per city, with the
threshold verdicts, the freezing classification and the date label resolved server-side. No
new route and no second round trip: the outlook rides on the endpoint the weather screen
already calls, which keeps the Mini App's 2×2 navigation intact. The field is omitted rather
than sent empty, so a client that has never seen it renders exactly as before. The screen
gains a horizontally scrollable strip of day chips; the freezing state is carried by a glyph
as well as a border colour, so it survives a monochrome reading.

Review

Reviewed on three lenses in parallel — correctness and tests, security and operations,
performance and architecture — then re-reviewed solo over the fixes. No finding was P0 or P1
on either pass. Ten fixes were applied on top; each carries a test verified to fail when the
fix is reverted, except where noted.

The two that mattered:

• A day leaving the window read as a change, and as a clearing. A signature spans the
  days after the baseline and the baseline advances every morning, so the day that became
  today left the signature on its own with nothing in the forecast having moved. The gate
  read that as a change and sent; the diff called the arriving day cleared. A city forecast
  4.2 mm of rain was told, on the morning it rained, that the day had cleared — and got one
  such message per roll-off day, which in a wet week is the daily-whatever-happens digest the
  content gate exists to prevent. The stored signature is now pruned to today's window before
  it is compared or rendered, while the new one is stored unpruned. A mechanical walk over 20
  consecutive mornings against a frozen dataset produces zero spurious clearings, zero
  swallowed changes, and one send per genuinely new day.
• The range decode trusted the upstream array length. Bounded only by the 1 MiB response
  cap — roughly 15,000 days — while two invariants rested on a bound nothing enforced: the
  table has no archive tier because it is bounded at locations × 16, and a whole fetch is
  written in one BEGIN IMMEDIATE, which takes the WAL write lock at BEGIN. The decode now
  truncates at the horizon and drops any date past a window measured from the response's own
  first date (the clock is the wrong frame — forecast dates are city-local, and a host whose
  time has not synchronised would filter a good response to nothing), with an absolute
  one-year ceiling for the one thing a relative bound cannot catch: retention deletes the
  past, so a far-future row would be permanent. A daily[] that yields nothing storable is
  now an error rather than a silent success that left captured_at unmoved, holding the
  daily gate open so the location refetched on every tick behind a fetched=1 failed=0 log.

The rest: the digest read the forecast once per subscription instead of once per location;
the date formatter and the zero-state glyph table each existed twice, the glyph copies
disagreeing on what to show for a day with no temperature bounds; the weather view took a
fresh clock inside its per-city loop, so two cities could straddle a midnight; the forecast
read failed the whole response where the observation read beside it tolerates ErrNotFound;
and the decoder's skipped-date test asserted dates but no measurement, so an output-position
indexing bug passed it.

Deferred deliberately, each with an issue: the fetch gate throttles successes only, so a
provider outage costs far more than one call per location per day (#132); Open-Meteo
transport errors carry coordinates into the log through *url.Error (#133); the release
flips the channel symlink before running migrations (#134); and CLAUDE.md is over its own
20k budget (#135). Accepted without change: the digest signature encodes flags rather than
amounts, and a signature-version bump re-notifies the quiet cohort once — both are the
plan's explicit design. One fix ships without a regression guard and is called out as such:
hoisting the clock out of the weather view's loop would need a clock seam on the service to
test, which means changing NewService and every caller for one assertion.

Notes

• Privacy: weather_forecast_days holds public meteorological numbers keyed on a
  location and has no user column at all. notify_state is system-managed dedup state of
  the same nature as the existing alert_latched and last_notified_at. Neither is
  identity-adjacent; no policy change was needed.
• The historical backfill-migration tests no longer seed through
  WeatherUserCityRepository. Its SQL names the columns of the current schema, so a test
  pinning a frozen snapshot broke on the new column and would have broken on every column
  added after it.
• The full -race suite does not build on the development machine: it is an 8 GB Pi
  with no swap, and modernc.org/sqlite/lib under race instrumentation is OOM-killed by the
  kernel. Every package that does build under -race is green, and the whole suite plus
  go vet is green without it. CI is the gate for the race build.
• Plan: plans/017-long-range-weather-outlook.md.

Refs #127