TARIFF-17: a price component that varies by hour has somewhere to live

`price.py` modelled the whole non-energy part of a Belgian bill as ONE flat
scalar. This adds `price_taxes_profile`, which carries the TAXES component as
a period table, and makes `assemble()` evaluate it at each point's own instant.

⚠️ THE FLAT SCALAR WAS NOT A WRONG NUMBER, AND THIS IS NOT A CORRECTION OF ONE.
The optimiser reads exactly two quantities off a series - the spread
`max - min` over the firm points, and which hour is cheapest - and an additive
constant identical in every hour cancels out of the first and leaves the second
where it was. It is provably inert. Measured, and printed by test_price.py 16b
on every run: with a flat taxes figure of 0.00, 0.0739, 0.1198, 0.1327 or 1.00
EUR/kWh the same 24-hour feed is cheapest at 13:00 in all five cases and its
spread is 0.1500 EUR/kWh in all five cases. What was missing is anywhere for an
HOUR-VARYING non-energy component to live. This is a missing capability, not a
bad constant.

Belgium has one. Fluvius distribution is a single rate - its tariff-card row
reads `Normaal | Uitsl. nacht`, where exclusive night is a separate physical
circuit and not a night register - so nothing changes for the reference site in
Flanders. The Walloon DSOs and Sibelga are on the same card with four columns,
`Enkelvoudig | Dag | Nacht | Uitsl. nacht`, and the gap is real money (c/kWh):
ORES 13,27 / 7,39; AIESH 15,17 / 8,21; Tecteo RESA 12,20 / 7,01; Sibelga
9,39 / 7,10; ORES IMPACT 2026 16,578 / 5,090.

⚠️ AND THE BANDS ARE ANTI-CORRELATED WITH WHAT THE BATTERY WANTS TO DO. The
cheap network hours are the cheap spot hours, so flattening them does not shift
the curve - it UNDERSTATES the spread and declines cycles that would have paid.
Same feed, same markup, the only difference being the taxes argument:

    flat 0.0000 / 0.0739 / 0.1198 / 0.1327 / 1.0000
                                       -> cheapest hour 13, spread 0.1500
    ORES dag 0.1327 / nacht 0.0739     -> cheapest hour 03, spread 0.1788

The regression check grades WHICH HOUR IS CHEAPEST, not the spread: an
implementation that reads the table once and adds one number to every point is
the LEVEL bucket wearing a period table - right magnitude, wrong shape - and a
spread assertion passes on it. Measured: hoisting the lookup out of
`assemble()`'s loop (+17 B) is red on six named checks in test_price.py and
GREEN in the other 28 files.

ONE GRAMMAR, NOT TWO. `static_tariff.py` already shipped the periods, the day
selectors, the tiling rule and the DST handling, so `parse_taxes_profile()` is
the same parser with the option name and the "what this number means" clause as
arguments. A second tiling rule would be a second set of 23- and 25-hour-day
bugs. test_static_tariff.py section 10 pins that two ways: by parsing every
module under `app/` and asserting the grammar is defined in exactly one of
them, and by deriving each of thirteen refusal sentences for the new option
from the old option's own sentence rather than transcribing them.

`Component.TAXES` semantics, `code_leaks()` and the double-counting guarantee
are untouched. The new key joins FRAMEWORK_KEYS, BANNED_IN_PLUGIN_CODE is
derived from that set, and a plugin that names it is refused at `register()`.
It reaches both plugins that take taxes - `custom_formula` ({ENERGY, MARKUP})
and `generic_dayahead` ({ENERGY}) - and not `manual_csv`, which is all-in: the
table is routed through `capabilities().adds`, exactly as the scalar is.

⚠️ A MALFORMED TABLE IS REFUSED AT STARTUP, NOT AT THE NEXT FETCH. It is read
on the ~30 s planning path, and a table that first fails at 03:00 is a site
that stops pricing at 03:00, which §11.4 turns into a quiet fallback
indistinguishable from a healthy fixed-tariff day. validate.py refuses three
things: a table that does not tile the day; a table set beside a NON-DEFAULT
`price_taxes_eur_kwh`, because the table wins and the scalar would then be a
number the operator typed that decides nothing; and a whole card typed in
CENTS, which is how these figures are printed. That last rung is not a
restatement of the parser's +-10 EUR/kWh bound - ORES's 13,27 trips the parser,
but Sibelga's entire card, 9,39 and 7,10, is under it and would otherwise have
started as a 9.39 EUR/kWh levy. Both rungs are graded by the REASON each gives,
and mutating them together (TEST-16) moves three rows.

NOTHING CHANGES FOR A SITE THAT DOES NOT SET IT. The option ships "", and the
scalar path is unchanged arithmetically rather than merely in intent:
test_price.py 16f reproduces the pre-TARIFF-17 expression and compares 12
capability/scalar combinations point for point with `==`.

13 mutations, every one red on a named check, ledger in test_price.py below
section 16k with byte deltas and the one equivalent mutant named. 29/29 green.

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

goodwe_controller/DOCS.md

@@ -1870,6 +1870,129 @@ uses the result as a cheap-window hint for the maintenance charge. They are
 — configure two of them and the add-on refuses to start, naming the conflict,
 because the add-on reads exactly one and the loser is silent. Use one.
 
+### The three buckets — which price components can move a decision (TARIFF-17)
+
+**Read this before adding a price component of any kind.** The optimiser reads
+exactly two quantities off a price series, and nothing else:
+
+- the **spread**, `max − min` over the *firm* points, weighed against
+  `cycle_cost_threshold_eur`; and
+- **which hour is cheapest**, `min(firm, key=…)` — the hour a battery would
+  buy in.
+
+Every component of a Belgian bill reaches those two through one of three
+buckets, and which bucket it is in is a property of its *shape*, not of its
+size:
+
+| bucket | what it looks like | reaches the decision? |
+|---|---|---|
+| **LEVEL** | additive, **identical every hour** | **No — provably.** An additive constant cancels exactly in `max − min`, and adding it to every point leaves the argmin where it was |
+| **SPREAD** | **multiplicative** on the spot index | **Yes.** It scales the spread against a fixed `cycle_cost_threshold_eur` |
+| **ORDER** | **varies** by hour, block or day-type | **Yes, and worst.** It changes *which hour is cheapest* |
+
+Measured on the real arithmetic (`test_price.py` section 16b, printed on every
+run): with a flat taxes figure of 0.00, 0.0739, 0.1198, 0.1327 or 1.00 EUR/kWh,
+the same 24-hour feed is cheapest at **13:00 in all five cases** and its spread
+is **0.1500 EUR/kWh in all five cases**. That is the LEVEL bucket doing
+nothing, and it is not a rounding artefact — it is arithmetic.
+
+Three consequences worth having in mind:
+
+1. **`price_taxes_eur_kwh` is not a wrong number and never was.** It sits in
+   the LEVEL bucket and *cannot* distort either quantity. What it also cannot
+   do is express a component that varies by hour — which is why
+   `price_taxes_profile` exists. The defect TARIFF-17 closed was a **missing
+   capability**, not a bad constant.
+2. **`custom_formula`'s `factor` is a SPREAD component, and its `offset` is
+   LEVEL.** The contract price is `(factor × index + offset) × (1 + VAT)`, so
+   the spread over a feed is `factor × (1 + VAT) × (max index − min index)` —
+   the offset drops out entirely, and the spread is *proportional* to `factor`.
+   Moving `factor` from 0.100 to 0.10812 therefore moves the spread by exactly
+   **+8.1 %** on any feed whatever. A coefficient typed one digit wrong is not
+   a small pricing error; it is a different trading threshold. The VAT rate is
+   multiplicative on the whole expression, so it is SPREAD too.
+3. **A check that grades the spread is grading the wrong bucket.** An
+   implementation that reads an hour-varying table *once* and adds the same
+   number to every point produces a series of the right magnitude and the wrong
+   shape — the LEVEL bucket wearing a period table. The spread would look
+   plausible; the buy hour would be wrong. So the regression check for an
+   ORDER-bucket component asserts **which hour is cheapest**, not how big the
+   spread is (`test_price.py` 16c and 16d).
+
+⚠️ **Where the buckets are today.** `price_markup_eur_kwh`,
+`price_taxes_eur_kwh` and `custom_formula`'s `offset` are LEVEL.
+`custom_formula`'s `factor` and its VAT rate are SPREAD. `price_taxes_profile`
+is the only ORDER component the add-on has. Anything added next belongs in one
+of the three, and saying which is part of adding it.
+
+### Levies and VAT by time of day (`price_taxes_profile`)
+
+**Leave this empty unless your network tariff really does have a day and a
+night rate**, which in Flanders it does not. Fluvius distribution is a single
+rate: its row on the tariff card reads `Normaal | Uitsl. nacht`, and
+*exclusive night* is a **separate physical circuit** (a night-storage heater on
+its own meter), not the night register of a dual-rate meter. For a Flemish site
+the flat `price_taxes_eur_kwh` is correct, and this option changes nothing.
+
+**Wallonia and Brussels are different, and the same card proves it.** The
+Walloon DSOs and Sibelga get four columns — `Enkelvoudig | Dag | Nacht |
+Uitsl. nacht` — and the day/night gap is real money (c€/kWh):
+
+| DSO | enkelvoudig | dag | nacht | gap |
+|---|---|---|---|---|
+| ORES | 11,98 | 13,27 | 7,39 | **5,88** |
+| AIESH | 13,64 | 15,17 | 8,21 | **6,96** |
+| Tecteo RESA | 11,06 | 12,20 | 7,01 | 5,19 |
+| Sibelga (Brussels) | 9,39 | 9,39 | 7,10 | 2,29 |
+| ORES IMPACT (2026) | — | 16,578 | 5,090 | **11,49** |
+
+⚠️ **The bands are anti-correlated with what the battery wants to do.** The
+cheap network hours are the cheap spot hours. So flattening them does not
+merely shift the curve — it **systematically understates the true spread**, and
+the add-on declines cycles that are genuinely profitable. On ORES's bands over
+one ordinary winter weekday the measured effect is: cheapest hour **13:00 →
+03:00**, spread **0.1500 → 0.1788 EUR/kWh**.
+
+It is written in **exactly the same grammar as `static_profile`** — the same
+periods, the same day selectors, the same rule that every day type is covered
+once with no gap and no overlap, the same DST handling. It is literally the
+same parser; there is no second tiling rule, because a second one would be a
+second set of 23- and 25-hour-day bugs.
+
+```json
+{"periods": [
+  {"name":"dag",  "from":"07:00","to":"22:00","days":"mon-fri","eur_per_kwh":0.1327},
+  {"name":"nacht","from":"22:00","to":"07:00","days":"mon-fri","eur_per_kwh":0.0739},
+  {"name":"nacht","from":"00:00","to":"24:00","days":"sat,sun", "eur_per_kwh":0.0739}]}
+```
+
+- ⚠️ **`eur_per_kwh` here is the LEVIES ALONE, not an all-in price.** It is the
+  non-energy part of the bill for that band, and the add-on adds it to whatever
+  your price source publishes — exactly as it adds the flat figure. This is the
+  one place the two options differ in meaning while sharing a grammar, and the
+  refusal you get for leaving the number out says which one is wanted.
+- ⚠️ **The card prints cents. This option takes EUR.** ORES prints `13,27`;
+  type `0.1327`. A whole card typed in cents is refused at startup, naming both
+  bands and the factor — including the cards (Sibelga's 9,39 / 7,10) whose
+  figures are small enough to slip past the ±10 EUR/kWh bound the parser holds
+  every price to.
+- ⚠️ **Set this *or* `price_taxes_eur_kwh`, not both.** The table wins when it
+  is set, so a scalar left at a non-default value beside it would be a number
+  you typed that decides nothing. That is refused at startup rather than
+  silently resolved; leave `price_taxes_eur_kwh` at its shipped `0.06` when you
+  fill this in.
+- A **malformed table is refused at startup**, not at the next fetch. It is
+  read on the ~30 s planning path, and a table that first fails at 03:00 is a
+  site that stops pricing at 03:00 — which §11.4 turns into a quiet fallback
+  that looks exactly like a healthy fixed-tariff day.
+- It applies to the components the framework **adds**: `generic_dayahead`
+  (which declares `{ENERGY}`) and `custom_formula` (which declares
+  `{ENERGY, MARKUP}`) both get it. `manual_csv` publishes an all-in figure and
+  is untouched — the table is routed through the same `capabilities().adds`
+  rule as the scalar, not bolted on.
+- It does **not** apply to `static_profile`, whose prices are already all-in,
+  nor to `export_price_eur_kwh`.
+
 ### Static day/night and fully-fixed tariffs (`static_profile`)
 
 Most Belgian households are **not** on a dynamic contract, and an EMS that only