Sync 0.19: the Forecast tab extends a cheap run with control's gap (TARIFF-24)

UX-54's Forecast tab (release/1.0) re-plans tomorrow's cheap run as control
will, with the gap `required`. It still added the "no weather" x1.5 always,
while control (TARIFF-24, from master) drops it when a forecast is read. In
the UX-54 scenarios the tab asked 0.225 where control needs 0.15. It now asks
`arbitrage.weather_uncertainty(True, c.solar_fc)`, so the two agree again, as
they did on release/1.0 alone. Display only; no control change. The tab's
blocks in every UX-54 scenario, every 2 h, are identical to release/1.0.

test_ux54.py pins it (the old line fails it). The TARIFF-24 DECISIONS note
names the tab as the fourth place that reads the rule.

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

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

@@ -50,9 +50,10 @@ was one input judged twice.
 **The rule** (`arbitrage.weather_uncertainty()`). With battery modes on and a
 usable forecast (`solar_fc` not None, the day plan's own test) the doubt is
 not added: the gap needed is the cycle cost, widened by the price product only.
-No forecast, or a stale or unusable one: 1.5 x, as before. It is read in three
+No forecast, or a stale or unusable one: 1.5 x, as before. It is read in four
 places that must agree: the run plan (`_price_runs()`), the charge gate
-(`_mode_roles()`) and Home's mirror (`homeview.trade_verdict()`). The forecast
+(`_mode_roles()`), Home's mirror (`homeview.trade_verdict()`) and the Forecast
+tab's longer cheap run (`dayview.py`, from release/1.0). 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, with one exception:
 a run planned with a forecast that is under way keeps that gap to its end