TARIFF-09: ask the day-ahead feed for the horizon it was handed

`generic_dayahead.fetch()` accepted `since` and `until` and requested the
bare `?bzn=BE`, which answers ONE Brussels day. Everything past today was
then filled from yesterday's profile by FCST-04, flagged provisional, and
§8.3 drops provisional hours from the trade set -- so the optimiser never
saw tomorrow as firm, at any hour of any day, and nothing reported it.

Measured on 4257e38 at 2026-09-10T09:00+02:00, 48 h horizon, live feed,
yesterday seeded through the shipped read path:

    60 firm points (15 whole hours) + 33 carried hours of 48 requested
    carried: 24 h on 2026-09-11, 9 h on 2026-09-12
    arbitrage(0.10): buy 11:45 and sell 19:45 -- BOTH on 2026-09-10
    firm local days = [2026-09-10]

The ceiling was structural: with a one-day window, at hour H a 48 h horizon
is at most 24-H firm and 24+H carried. At 23:00 that is 1 and 47, and the
remaining firm spread (0.0464 EUR/kWh) no longer clears the default 0.10
threshold, so arbitrage is refused outright. FCST-04's fill covers the
window until the ~13:00-14:00 CET auction; it was never meant to cover
every hour of every day.

The data exists and the endpoint serves it: verified 2026-09-10T07:45:49Z,
`?bzn=BE&start=2026-09-09&end=2026-09-10` returns 192 quarter-hours across
two local days. Committed unmodified beside TARIFF-08's captures, with the
URL, retrieval time and sha256 recorded and RE-DERIVED by the replay.

THE RANGE IS DERIVED ON THE BRUSSELS CALENDAR, not the UTC one. 22:30 UTC
in summer is already tomorrow in Belgium, so a UTC-derived start asks for
the day the controller has just left and drops the day it is standing in,
for the last one or two hours of every day. That is `_bdate()`'s lesson one
layer up with a worse consequence: `_bdate()` misfiles an hour, this never
fetches it. `until` is exclusive, so local midnight belongs to the day
before it; an inverted window collapses to one day rather than a backwards
range. Both ends are graded and both are driven red by mutation.

After, same code path and window, a feed serving both days: 39 firm hours
and 9 carried (was 15 and 33), firm across TWO Brussels days, and the
permitted cycle buys on one day and sells on the next.

`price_feed_url` IS THE EXACT URL AND THE PLUGIN APPENDS NOTHING. `start`/
`end` are this feed's spelling and the provider declares a second host
whose parameters are different, so merging would produce a request nobody
typed and the short horizon anyway. The cost is real, so it is not silent:
a WARNING on the shipped logger at fetch time names the consequence and the
start..end that would otherwise have been asked for. `dated_feed_url()`
refuses to append to a base that already carries a query string, so the
blind-append shape cannot come back by edit.
DECISIONS/TARIFF-09-the-range-and-the-override.md argues the alternative.

Before publication nothing regresses and it is graded, not assumed: at
09:46 CEST the two-day request came back byte-identical to the one-day
body, and that stays a `series` of what exists with FCST-04 filling the
rest. A `no_data` there would switch a working site's arbitrage off every
morning -- the mutation that adds that rule is red by name.

The plugin contract is still NOT enforced: three shipped plugins point at
endpoints nobody has verified, and a rule obliging them to pass a range
would be satisfied by an invented parameter name -- TARIFF-08's defect
moved from the response to the request. Which plugins consume the range is
pinned as a literal instead.

11 mutations, all red, no survivors; each applied to a fresh copy of the
tree rather than reverted, through tools/mutation_run.sh. One is +0 B (a
single price digit inside the committed capture) and the re-derived sha256
catches it. MUTATION.md habit 20 records why a fixture could never have
reached this: a captured body is the answer to a URL, and no property of a
body says which URL was asked for. All 29 suites green.

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

goodwe_controller/DOCS.md

@@ -1360,7 +1360,7 @@ does, and only after you have read why.
 | `price_taxes_eur_kwh` | Levies and VAT, EUR/kWh. Same rule |
 | `export_price_eur_kwh` | The **injection** price. A separate scalar, not a series — see below |
 | `price_csv_path` | Where `manual_csv` reads its file |
-| `price_feed_url` | Override the plugin's default feed. Only a host the plugin itself declares is accepted |
+| `price_feed_url` | Override the plugin's default feed. Used **exactly as written** — the add-on appends nothing to it, including the date range, so an override gets whatever horizon that URL returns. Only a host the plugin itself declares is accepted |
 | `price_horizon_h` | How far ahead to ask for, hours |
 | `price_timeout_s` | Per-request timeout |
 | `static_profile` | A static day/night or fully-fixed tariff. Empty by default — see below |
@@ -1408,6 +1408,29 @@ point `price_feed_url` somewhere else:
 * Belgium moved to a **15-minute market time unit** on 2025-10-01, and the feed
   followed. A published day is **96 points, not 24**. Nothing in the add-on
   assumes either spacing, and nothing aggregates the quarters away.
+* The request **names the days it wants**, derived from the horizon on the
+  **Brussels** calendar — `?bzn=BE&start=2026-09-09&end=2026-09-10`, two
+  inclusive local dates. Without that the feed answers a single day, and
+  everything past today would be carried forward from yesterday's profile and
+  flagged provisional — which §8.3 excludes from arbitrage, so tomorrow would
+  never be tradeable at any hour. The calendar is Brussels rather than UTC
+  because 22:30 UTC in summer is already tomorrow in Belgium.
+
+**What you get before the auction publishes.** The day-ahead auction clears at
+about 13:00–14:00 CET. Ask for tomorrow before that and the feed returns fewer
+days than requested — that is normal, not a failure. The add-on keeps the
+series of what exists and fills the remaining hours from yesterday's profile,
+flagged provisional; arbitrage runs on the firm hours and ignores the flagged
+ones. So a dynamic site's plan is part firm and part carried every morning and
+fully firm once tomorrow is published, and neither state is an error.
+
+⚠️ **If you set `price_feed_url`, you keep the short horizon.** The override is
+sent exactly as you wrote it and the add-on adds no `start`/`end` to it, because
+those are this feed's parameter names and an override may point somewhere with
+different ones — rewriting a URL you typed is how a request nobody intended gets
+made. The consequence is a **`WARNING` in the log on every price refresh**,
+naming the range that would otherwise have been requested. If you only wanted a
+different host and not a different horizon, the fix is to clear the option.
 
 If the arrays ever come back different lengths, or the unit stops saying
 EUR/MWh, the fetch is refused outright rather than trusted in part: a price