TARIFF-24 round 3: a run planned with a forecast keeps its gap to its end

Losing the solar forecast mid-run used to widen the gap at once and stop a
grid charge (and a sensor that went unavailable for a minute stopped and
restarted it). A run under way when the forecast is lost now keeps the gap it
was planned with until it ends (Controller.weather_held(), recorded by
_wx_track() each cycle a forecast is read); the wider gap applies from the next
run. The plan key holds the hold state so the plan rebuilds when it ends. Home's
mirror (homeview.trade_verdict) asks the same weather_held(now).

Tests: test_tariff24_weather.py part 4 (going: the charge continues to the run's
end, the next run is not_worth; flap of one and two reads: no stop, no restart;
Home agrees) and a test_modes_p4.py scenario that runs a forecast day at a gap
between 1x and 1.5x the cycle cost. DECISIONS wording follows.

Co-Authored-By: Claude <noreply@anthropic.com>

goodwe_controller/DECISIONS/TARIFF-24-modes-need-the-tariff-task.md

@@ -54,8 +54,10 @@ No forecast, or a stale or unusable one: 1.5 x, as before. It is read in three
 places that must agree: the run plan (`_price_runs()`), the charge gate
 (`_mode_roles()`) and Home's mirror (`homeview.trade_verdict()`). The forecast
 is read at most every 60 s and the plan key already holds "forecast or not", so
-the gap follows in the cycle the read changes, both ways. A run already under
-way is kept to its end (`priceruns.keep_started()`), as for any change.
+the gap follows in the cycle the read changes, both ways, with one exception:
+a run planned with a forecast that is under way keeps that gap to its end
+(`Controller.weather_held()`), so a sensor that goes unavailable does not stop
+or restart a charge. The wider gap applies from the next run.
 
 **Not changed.** Modes off (the site trade) keeps the doubt always. The
 shipped cost 0.10 still needs a gap of 0.10 even with a forecast: a 0.08