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/DOCS.md

@@ -1424,6 +1424,40 @@ distinct state from "prices, all of them zero": the plan is marked provisional
 and arbitrage is disabled, per the degradation matrix. It never falls back to a
 price of zero, which would read as free electricity.
 
+#### The hours the feed has not published yet (FCST-04)
+
+A day-ahead auction publishes tomorrow's prices once a day, at **14–16 h CET**.
+Before that, the feed is serving today and nothing else — so a `price_horizon_h`
+of 48 asks for 48 hours and gets back the ten or fifteen that are left in the
+day. Until FCST-04 those other hours were simply **absent** from the plan: not
+priced badly, not flagged, just missing, and nothing said so.
+
+Now the add-on keeps the **published prices of the last few days** in
+`/data/price_history.json` and fills every unpublished hour of the horizon with
+yesterday's price for the same Brussels wall-clock hour, flagged
+`provisional: true`. Two things follow, and the second one matters more:
+
+- **The plan says it is guessing.** *Tariff* on the status page reads
+  `provisional` through the morning, because half its hours are. Before, a
+  half-length plan looked completely settled.
+- **Nothing may trade on a carried hour.** §8.3 forbids acting on a provisional
+  price, so arbitrage drops those hours from the trade set entirely — it needs a
+  buy hour and a sell hour that were *both* published. Carrying a price forward
+  widens what the optimiser can **see**; it never widens what it may **do**.
+
+The plan is also now cut to the horizon you asked for, which means **hours that
+have already elapsed are no longer in it**. That is a real change to arbitrage:
+a cheap night that has already gone used to sit in the series as the cheapest
+hour of the day, and a cycle can never buy in an hour that is past — so the
+trade was quietly never taken. The spread is now taken over hours still ahead.
+
+A new status row, **Price history**, says which days are held and how many hours
+each has. If it reads `empty` or `unavailable`, nothing is carried, the horizon
+is as short as the feed makes it, and every other guarantee is unchanged — a
+cache that cannot answer is not allowed to be a controller that cannot regulate.
+The store is rebuilt by the next successful fetch; on a brand-new install the
+first fill is possible the day after the first refresh.
+
 **Injection is priced separately** (`export_price_eur_kwh`). In Belgium it is
 often near zero, which by itself strongly favours self-consumption over export.
 It is a single number rather than a curve because no supported supplier