Snow accumulation can pass the 12-month guard with a 364-day year #88

Found by an independent review of v0.4.0..v0.4.2, and verified.

What changes if we do it

snowfall, snowmelt and the four annual-derived snow variables stop being
written from a 364-day year at the January run.

What happens if we never do it

The wrong values are written once, and outputs_for_year() skips them as
existing thereafter, so they are never recomputed — then published.

The mechanism

The completeness guard added in #84 checks months of year on the hourly store.
But the accumulation path needs one day past year-end: accum_box slices
{year}-01-02T00:00 to {year+1}-01-01T00:00, because hourly_accum_to_daily
shifts back a day for the 06:00-UTC reset.

A store ending exactly at {year}-12-31T23:00 — the expected state at a January
run, since EDH advances on month boundaries — passes everything:

store ends 2026-12-31T23:00
  months_available(2026) = 12    -> guard passes
  accum daily series     = 364 days
  monthly resample bins  = 12    -> the post-compute == 12 check passes too

The only signal is the existing WARN {v}: got 364 days, expected 365-366, which
nothing acts on.

Suggested fix

Require the extra day before computing sf/smlt and anything derived from them:

has_next_day = hourly_ds.valid_time.sel(
    valid_time=slice(f"{year+1}-01-01T00:00", f"{year+1}-01-01T00:00")).size == 1

Or promote the existing n_days < 365 WARN to a skip for the affected variables.
The state variables (sde, rsn, snowc) are within-year and unaffected.