TARIFF-01: measure the month's billed peak, and make it survive a restart

The 15-minute block average was already built and unwired. p1.QuarterAverager
computes clock-aligned 900 s blocks, time-weighted over irregular telegram
spacing, offtake-only and per-phase; P1Ingest.blocks was a 96-entry list in
memory that a restart erased. So this is the persistence and the monthly
reduction, not a second accumulator - a second one would be a second source of
truth for the exact quantity the money depends on.

BLOCKS, NOT A SLIDING WINDOW. The card says "rolling"; 9.1 bills "the highest
15-minute average offtake" and states its own worked case per QUARTER - one
4998 W quarter moving a monthly peak from 4832 to 5013 W. A trailing window
reports a peak the meter never bills, and reports it HIGH: a burst straddling
:15 fills the window completely while contributing to two block averages at
partial weight.

DELIVERED, NOT INTENDED. tariff.py only ever sees P1Sample - the meter's own
reading - and never a setpoint. SAFETY-20's open question does not arise for a
capacity tariff: the utility integrates the current that flowed.

AN UNREADABLE STORE IS NOT A ZERO PEAK. peak() answers OBSERVED / NO_RECORD /
NOT_OBSERVED with peak_w None unless observed, which is riglock.holder()'s fix
applied to something that spends money. A peak read as 0 W hands SAFETY-07
maximum headroom and disarms the guard at the moment its own storage breaks.

Restart mid-block resumes the accumulator through a new snapshot()/restore()
pair, checkpointed every 15 s and cleared in the same breath as a block close.
The held sample keeps its ORIGINAL timestamp, so an outage is integrated under
the same max_hold_s rule a running process would apply. quarter_start is the
primary key and a re-bank may only ever RAISE a figure.

Calendar months are LOCAL: a quarter starting 22:15 UTC on 31 August bills in
September.

No new option (the limit is the existing peak_cap_w), so config.yaml and
validate.py are untouched and CFG-03 is not widened. No second peak entity:
peak_forecast_entity stays the input to maintenance_charge_floor(), because
repointing that consumer changes what moves energy and belongs to SAFETY-07.

AC 3 is NOT met. It asks for 30 days of replay; two days of this house's real
meter exist and are committed here. test_tariff.py part 9 replays them, reports
the percentage next to the sample size in days, and asserts nothing about 95 %.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC

goodwe_controller/CHANGELOG.md

@@ -2,6 +2,59 @@
 
 ## Unreleased
 
+**The capacity-tariff peak is now measured, banked and survives a restart
+(TARIFF-01).** New `app/tariff.py`. The 15-minute block average itself was
+already built and unwired - `p1.QuarterAverager` computes clock-aligned 900 s
+blocks, time-weighted over irregular telegram spacing, offtake-only and
+per-phase - and `P1Ingest.blocks` was a 96-entry list a restart erased. This
+adds the SQLite behind it (`/data/tariff.db`): one row per completed quarter in
+the indefinite 15-min tier, one row per calendar month in the permanent peak
+tier, and no `DELETE` against either anywhere in the module.
+
+**Blocks, not a sliding window.** The card says "rolling"; 9.1 bills "the
+highest 15-minute average offtake", stated per QUARTER. "Rolling" here means
+continuously updated, not a trailing-15-minutes window - a trailing window
+reports a peak the meter never bills, and reports it HIGH, because a burst
+straddling :15 fills it completely while contributing to two block averages at
+partial weight.
+
+**A restart mid-block resumes it, and a restart that outlives the block banks
+it.** `QuarterAverager` grew `snapshot()`/`restore()`; the tracker checkpoints
+the open block every 15 s (worst case 1.7 % of one quarter) and clears the
+checkpoint in the same breath as a block close. The held sample keeps its
+ORIGINAL timestamp across the restart, so the outage is integrated under the
+same `max_hold_s` rule a running process would apply and uncovered seconds drag
+the closed block DOWN rather than being held forward. `quarter_start` is the
+primary key and a re-bank may only ever RAISE a figure, so a replay cannot
+double-count and a partial re-run cannot lower a quarter already measured.
+
+**An unreadable store is not a zero peak.** `peak()` answers `OBSERVED` /
+`NO_RECORD` / `NOT_OBSERVED` and carries `peak_w = None` unless observed - the
+`riglock.holder()` fix applied to something that spends money. A peak read as
+0 W hands SAFETY-07 maximum headroom and silently disarms the guard at the
+moment its own storage breaks, so there is no accessor that defaults it: a
+caller who forgets gets a `TypeError`, and the status page prints a different
+row for "no quarter yet" than for "the database did not answer".
+
+**Calendar months are LOCAL, blocks are UTC.** A quarter starting 22:15 UTC on
+31 August bills in September. Block alignment still needs no timezone.
+
+**No new option, and no second peak entity.** The soft limit is the existing
+`peak_cap_w`; `config.yaml` and `validate.py` are untouched, so CFG-03 is not
+widened. `peak_forecast_entity` stays the input to `maintenance_charge_floor()`
+- repointing that consumer changes what moves energy and belongs to SAFETY-07.
+
+**It measures and nothing else.** No claim, no clamp, no command; graded on the
+parsed syntax in `test_tariff.py`, which also proves the same grader lights up
+on `main.py`. Per SAFETY-20, the quantity is DELIVERED power - `tariff.py` only
+ever sees `P1Sample`, the meter's own reading, never a setpoint.
+
+**AC 3 is not met and the check says so.** It asks for 30 days of replay; two
+days of this house's real meter exist (2026-08-20, 2026-08-23), now committed as
+`scenarios/p1-net-*.jsonl.gz`. `test_tariff.py` part 9 replays them, reports
+the percentage under the shipped limit next to the sample size in days, and
+asserts nothing about the 95 % figure.
+
 **A computed setpoint over the rating now alarms instead of being clipped in
 silence (SAFETY-03).** The clamp was never the missing half - specs.md 10.3
 records an unclamped integrator climbing ~130 W per 4 s past 10 kW and reporting