FCST-04: the carry-forward fill reaches the plan, and the day it carries survives a restart

FCST-03 shipped `fill_from_yesterday()` complete and checked, and shipped the
consumers written for it - `TariffPlan.firm_points()`, `cheap_now()`'s refusal
of a provisional hour, and `arbitrage()`'s refusal 3, which drops provisional
hours from the trade set rather than refusing the whole series. It shipped NO
CALLER. Nothing in `app/` named the fill, so no series ever contained a carried
point and every one of those consumers was exercising its all-firm branch.

⚠️ THE DEFECT THAT PRODUCED WAS NOT AN ERROR ANYWHERE. `load_prices()` returns
what the feed published and nothing widened it to the requested horizon, so on
a dynamic site between midnight and the 14-16 h CET publication the plan
covered the rest of today and nothing more - measured on the fixture here, 24 h
against a 48 h request. `arbitrage()` then took `max - min` over that truncated
window and reported a spread. The number was real, the window was half the one
configured, and nothing said so: tomorrow evening's peak, the hour a morning
charge would be sold into, was not in the series to be compared against
anything. A missing hour is not a wrong price - it is an hour the optimiser
never learns exists.

WHAT THIS ADDS. `app/price_history.py` keeps the PUBLISHED prices of the last
KEEP_DAYS Brussels days in /data/price_history.json; `resolve_tariff()` gains a
required keyword-only `history` and fills every unpublished hour of the horizon
from yesterday's same-wall-clock hour, flagged. Persistence rather than a
variable on the refresh task, because the window the fill exists for is
midnight -> publication and an add-on restarted at 08:00 would otherwise spend
all of it on the truncated series. Not in state.json: the refresh runs every
1800 s and that file holds the maintenance history and SAFETY-02's latch.

⚠️ ONE CHANGE HERE MOVES ENERGY, AND IT IS NOT THE ONE THE CARD IS NAMED FOR.
Carried hours are provisional, so §8.3 keeps them out of the trade set: the
fill widens what the optimiser can SEE, never what it may DO, and
test_price_history.py checks that so it cannot be overclaimed later. What does
change a trade is that the filled series is windowed to [since, until), so
hours that have ALREADY ELAPSED are no longer in the spread. Before, a cheap
night that had gone sat in the series as the day's cheapest hour - and a cycle
cannot buy in an hour that is past, so the trade was quietly never taken.
Section 2 grades this by finding the cheapest firm hour with and without the
fill and showing it MOVES, from 02:00 UTC to 08:00 UTC on the fixture.

⚠️ A DEAD FEED IS STILL §11.4, NOT YESTERDAY. The fill runs only on a `series`
read. The two are indistinguishable to the optimiser - both 100 % provisional,
so arbitrage refuses on the firm-pair rung and `cheap_now()` is False - so
preferring yesterday's feed over the `static_profile` an operator configured
FOR that case would change a documented degradation for a difference only the
status page can see. That, and two more, in
DECISIONS/FCST-04-the-day-that-is-carried.md.

⚠️ THE ANTI-DECAY RULE IS AN ORDERING, NOT A VALIDATION, and saying so is more
useful than a guarantee that would not hold. Feeding the filled series back in
is how this rots - day 2 carries day 1's guesses, day 3 carries day 2's carry
of them, behind a `provisional` flag that stays TRUE while the NUMBER decays.
No value-level check can catch it: a carried point and `eneco_eddy`'s
published-provisional quarter are the same three fields with the same flag. So
`carry()` is the only public entry, it records BEFORE it fills, the filled
series exists only as a return value the object never sees again, and
test_price_history.py walks app/ for any other module naming `_remember` and
reads `carry()`'s AST to pin the order.

EVIDENCE. 29/29 test files pass in the CI image. Eight mutations driven against
app/price_history.py and app/static_tariff.py, __pycache__ purged before each
run per MUTATION.md/TEST-15: newest-record lookup (5 red), recording the filled
series (1), replace-instead-of-merge (10), UTC-date keying (10), removing the
fill call entirely (12), a lost price field defaulting to 0.0 (2), prune by
clock arithmetic (1), a degraded reason that stops naming its cause (1). No
survivors; baseline and revert both green. Three of those first crashed the
harness instead of reporting a FAIL - "it was refused" and "it broke on the way
to being refused" must not grade the same - so `why()` and `_priced()` were
added and the run repeated.

No option added, config.yaml untouched, and the CHANGELOG entry deliberately
picks no version: PKG-07's rule, and only the deployer knows whether 0.9.0's
image has been pulled.

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

goodwe_controller/DECISIONS/FCST-04-the-day-that-is-carried.md

@@ -0,0 +1,98 @@
+# FCST-04 — what "yesterday" is, and what the fill is allowed to reach
+
+Three decisions, recorded because each had a defensible alternative that a later
+reader would otherwise re-open from scratch.
+
+---
+
+## 1. The fill runs on a `series` read only. A dead feed still goes to §11.4.
+
+`fill_from_yesterday()` accepts a `no_data` read and will happily build a
+100 %-carried series from yesterday alone. `resolve_tariff()` does not let it:
+a feed that published nothing still falls to `_degrade()` and §11.4's own row —
+*"No price data → fall back to the static profile, mark the plan provisional,
+no arbitrage."*
+
+**Why not prefer yesterday's real prices to a coarse day/night profile?**
+Because it buys nothing the optimiser can use, and it silently replaces a
+fallback the operator configured.
+
+Measured, not assumed: a fully-carried series is 100 % provisional, so
+`TariffPlan.arbitrage()` finds fewer than two firm hours and refuses on §8.3's
+firm-pair rung, and `cheap_now()` returns False because `firm_points()` is
+empty. The §11.4 static fallback produces *exactly* those two answers. The two
+paths differ only in which numbers the status page shows.
+
+So the choice is between two identical control behaviours, and the tie-breaker
+is that `static_profile` is a documented option an operator fills in **for this
+case**. Overriding it for a cosmetic difference is a behaviour change nobody
+asked for.
+
+⚠️ **The consequence, stated so it is not discovered later as a bug:**
+`fill_from_yesterday()`'s `no_data` branch is not reached from production.
+It stays checked in `test_price_forecast.py`. Turning it on is a product
+decision — it would want a rule about how old a carried profile may be before it
+stops being offered at all — and not a wiring one.
+
+---
+
+## 2. "Yesterday" is a date, not the newest record.
+
+`newest()` is the obvious accessor and it is the one that decays. An add-on down
+from Friday to Monday would answer Friday's prices to a fill whose only
+vocabulary is `provisional: true` — a flag that says "this is a guess", never
+"this guess is three days old". Nothing downstream can tell the difference and
+nothing reports it.
+
+So `yesterday(stamp)` computes the Brussels date before `stamp`'s Brussels date
+and looks up **that** record. Anything else is `no_data` with a reason naming
+both the date wanted and the dates held.
+
+The cost is real and accepted: after an outage of more than a day, the first
+morning back has no fill. That is the honest state — there is no yesterday —
+and the horizon is short for one morning rather than wrong for several.
+
+---
+
+## 3. What is recorded is the provider's read, and the mechanism is ordering.
+
+Feeding the filled series back into the store is how this rots: day 2 carries
+day 1's guesses, day 3 carries day 2's carry of them, and after a week of a dead
+feed the "yesterday" being carried is a fossil of the last real publication.
+Every point still carries `provisional=True`, so the **flag never lies** — what
+decays is the number, behind a flag that is telling the truth.
+
+⚠️ **No value-level check can catch that**, and claiming one would be worse than
+claiming none. A carried point and a published-provisional point (`eneco_eddy`'s
+current quarter, §9.2) are the same three fields carrying the same flag. The
+difference is provenance, and provenance is not in the value.
+
+The defence is therefore an **ordering**, not a validation:
+
+- `carry()` is the only public entry point. It records its argument, then
+  returns the fill.
+- The filled series exists only as that return value. The object never sees it
+  again.
+- `_remember()` is private and called from exactly one place.
+- `test_price_history.py` walks `app/` and fails if any other module names
+  `_remember`, and reads `carry()`'s AST to confirm the record happens before
+  the lookup — so a later edit that reverses them is red rather than plausible.
+
+That ordering has a second benefit worth keeping: a feed that returns yesterday
+alongside today refreshes yesterday's record from live data *before* it is
+consumed as the profile.
+
+---
+
+## What this ticket does not claim
+
+It does not make a trade possible that yesterday's prices justify. Carried hours
+are dropped from the trade set by §8.3, and that is not a limitation to be fixed
+later — it is the rule.
+
+The one change that **does** move energy came from the windowing, not the
+carrying: the filled series covers `[since, until)`, so hours that have already
+elapsed are no longer in the spread. A cheap night that has gone used to be the
+series' cheapest hour, and a cycle cannot buy in an hour that is past — so the
+trade was silently never taken. `test_price_history.py` section 2 grades that by
+finding the cheapest firm hour with and without the fill and showing it moves.