MAINT-10 review: warn when HA did not answer and TZ is UTC; test the 3 s budget

HA can take minutes to start (2026-10-05, 502 from the proxy). Then TZ holds,
which the Supervisor sets from HA's zone, so the hour stays right; only a TZ
of UTC there now logs a WARNING asking for a restart. A test pins the 3 s
budget on the zone request (a mutant without it survived).

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

goodwe_controller/DECISIONS/MAINT-10-local-start-hour.md

@@ -13,8 +13,14 @@ peak guard outrank the drain.
 Home Assistant's `time_zone` (`GET /core/api/config`, 3 s budget) at startup,
 else the container's `TZ`, else UTC. One log line says which (WARNING only for
 UTC). Resolved once per start: a zone change in HA takes effect on the next
-add-on restart. The add-on image has tzdata (checked in `amd64-base:3.20`); the
-CI image does not, so the tests grade DST on `tariff._EUTimezone` too.
+add-on restart. HA can still be starting when the add-on starts (502 from the
+proxy, 2026-10-05); then `TZ` holds. HA pushes its zone to the Supervisor
+(hassio `push_config`), which stores it and sets it as the add-on's `TZ`
+(`docker/app.py`, Supervisor 2026.08.0), so the hour stays right. Only a `TZ` of
+UTC there logs a WARNING asking for a restart. No later re-resolve: the fallback
+already is HA's zone, so the rare UTC case gets a warning rather than more code.
+The add-on image has tzdata (checked in `amd64-base:3.20`); the CI image does
+not, so the tests grade DST on `tariff._EUTimezone` too.
 
 ## 2. DST