TARIFF-10: configuring a price provider is what fetches prices

amain() started the background tariff refresh only when arbitrage_enabled was
on, and that option ships false. run_tariff_refresh is the only caller of
resolve_tariff(), which is the only caller of price_history.carry() - so on a
shipped install with a price provider configured nothing was ever fetched: no
plan resolved, /data/price_history.json never created, the Price history status
row reading `empty` for the life of the install, and TARIFF-09's short-horizon
warning unable to fire because there was no fetch to warn about. Measured over
a 40 h two-instance soak on one feed: 0 requests and `present: false` across all
802 samples, against a resolved 132-point plan on the instance with arbitrage
armed.

git log -S puts the refresh task, its arbitrage.enabled() guard AND the DOCS.md
sentence saying a configured provider still fetches in the same commit - OPT-04,
bdd7f18; config.yaml has carried the claim since TARIFF-02, 852fc7c. The prose
and the code disagreed from the moment both existed and nothing compared them.
config.yaml and both translations additionally carried a claim that had rotted
the other way - "nothing consumes the price series yet", untrue since OPT-04
shipped the consumer. All four surfaces now say what the add-on does, and a
check pairs DOCS against the DRIVEN behaviour so they cannot drift again.

The gate is tariff_refresh_wanted() = provider_configured(opts) or
arbitrage.enabled(opts), and the `or` is a STRICT WIDENING: every configuration
that started the task before still starts it. The second term is not there for
symmetry. price_provider: off + a static_profile + arbitrage_enabled: true is a
configuration validate.py explicitly ACCEPTS and it trades - measured, at
cycle_cost_threshold_eur 0.05 on a 0.20/0.284 day/night profile,
ARBITRAGE_CHARGE -5000 W. Gating on the provider alone would leave that site's
tariff_plan at None forever and answer "no tariff plan has been resolved yet" on
every cycle, silently disarming a strategy the UI says is running.

Nothing acquires a periodic HTTPS call. With price_provider off, resolve_tariff()
answers out of the static profile without opening a socket (driven and counted:
0 requests), and the true shipped default - no provider, no trading - starts no
task at all. What decides whether a request leaves the machine is price_provider
and only that. The literal reading of the ticket's AC2 - drop the `or` - is one
token and is recorded in DECISIONS §3 with what it costs, for the owner.

AND NOTHING TRADES THAT DID NOT TRADE BEFORE. cycle()'s
`if arbitrage.enabled(self.o):` is untouched, and that is graded directly rather
than inferred from the gate having moved: Controller.cycle() is driven on a
resolved provider plan with the peak guard asserted clear, and arbitrage_enabled
is the only option that moves between the rows - false/false give +180 W
("loop -> 180 W") on both the cheap-now and dear-now plans, true/true give
-5000 W and +5000 W ("arbitrage -> ...").

TariffPlan.cheap_now() is deliberately NOT wired, decided rather than inherited
(DECISIONS §4). A provider-backed plan now exists on every configured site, so
Cheap window could read it - and Cheap window feeds the maintenance cycle's grid
top-up, the one place a price moves energy without trading being armed. On a
provider-only site static_status() returns False on every cycle, so adopting it
would take a paid grid top-up from never to sometimes. self.cheap stays on
static_status(); what adoption would take is listed rather than left implied.

THE CHECK THAT WOULD HAVE CAUGHT THIS is test_price.py section 13, and it grades
REACHABILITY FROM A CONFIGURATION rather than the shape of an `if` - the `if` was
exactly what somebody meant to write. amain()'s guards are EVALUATED against real
option dicts, whatever they are spelled as; the call graph under app/ is walked
to see whether the tasks those guards start arrive at resolve_tariff(), wherever
it has moved to; and then the fetch is DRIVEN with a counting transport, because
a graph is an argument and a counted request is an observation. What the
instrument cannot see is printed on every run, largest hole first.

Evidence: 29/29 green. 13 mutations in 14 runs - M10 re-run as M10b once it was
closed - each applied to a fresh cp -a of the clean worktree rather than
reverted (MUTATION.md habit 18), purged, :ro, -B. The
shipped defect - the gate back at arbitrage.enabled(opts), -4 B - is red on
seven named checks. Dropping the `or` (-27 B) is red on the strict-widening row;
removing cycle()'s trading gate (+8 B) is red on both AC3 rows. The instrument
is mutated too (habit 16): _reaches() always True and _task_sites() returning []
are both +0 B and both red.

Two findings are recorded rather than rounded off. provider_id() dropping
.strip() (-8 B) was a real SURVIVOR across four price suites - nothing fed a
padded provider id - and is closed in this commit by the padded-id pair; and the
first draft of the AC3 fixture fed five minutes of P1 telegrams, so whether the
peak guard was blind depended on where the wall clock sat inside the billing
quarter and the armed baseline failed to trade on some runs. It is 900 s now,
and the guard's clear state is a check rather than an assumption.

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

goodwe_controller/DOCS.md

@@ -1346,12 +1346,26 @@ does, and only after you have read why.
 > release ships the five provider plugins, the canonical all-in format they
 > emit, the config that selects one, and — new in OPT-04 — a price-arbitrage
 > strategy that trades on them. With `arbitrage_enabled: false`, which is the
-> shipped default, turning a provider on still fetches, validates and publishes
-> prices and changes no charging decision.
+> shipped default, **selecting a provider is what starts the fetch**: the feed
+> is read every 30 minutes, validated, and the day recorded in
+> `/data/price_history.json`, which the *Price history* status row reports and
+> the add-on log names at every refresh. No charging decision changes.
+>
+> ⚠️ **That has been the documented behaviour since OPT-04 and was not the
+> actual behaviour until TARIFF-10.** The background refresh was started only
+> when `arbitrage_enabled` was on — and it ships `false` — so an install with a
+> provider configured fetched nothing at all, never created the store, and read
+> *Price history: empty* for as long as it ran. If you configured a provider and saw an empty
+> Price history row, that is what you were looking at. Trading is unchanged and
+> is still `arbitrage_enabled` alone.
 >
 > `static_profile` below needs no network at all, so its cheap window is
 > computed on every cycle and reaches the maintenance cycle's grid top-up
-> whether or not arbitrage is armed.
+> whether or not arbitrage is armed. ⚠️ **And it is still the only source of
+> that window.** A provider-backed plan now exists on every configured site,
+> but *Cheap window* and the maintenance cycle's grid top-up read
+> `static_profile` and nothing else — a deliberate limit, recorded with what it
+> would take to change in `DECISIONS/TARIFF-10-fetching-is-not-trading.md`.
 
 | option | meaning |
 |---|---|
@@ -1670,6 +1684,14 @@ towards the firmware's 30 s failsafe. The plan refreshes every 30 minutes and
 retires itself if the refresh stops answering, at which point arbitrage stops
 with it.
 
+⚠️ **That refresh is not gated on this switch** (TARIFF-10). It runs when a
+`price_provider` is configured *or* when arbitrage is armed, so turning
+arbitrage off does not turn the price feed off — and a site with no provider
+that arms arbitrage on a `static_profile` keeps the plan it has always had. The
+only thing that decides whether a request leaves the machine is
+`price_provider`: with it `off`, the refresh resolves the static profile in
+memory and opens no connection.
+
 ### Site
 
 | option | meaning |