MAINT-10: every pack at N=2, the next DST days, plainer upgrade note

test_maint10.py part 10: at two inverters both packs get the site zone, the
real Controller is identical for 11 UTC and 13 Brussels, and two due packs
across 24/25 Oct 2026 and 27/28 Mar 2027 start at the local hour on
successive days; a pack freed in the repeated hour does not start there.
Part 3 adds 28 Mar 2027. DOCS: an existing install keeps its saved hour, now
read as local time; an hour set to make up for UTC goes back to 19.
DECISIONS: the SAFETY-83 gate is met; section on two inverters.

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

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

@@ -5,8 +5,8 @@ with the UTC hour, so the shipped 10 started at 12:00 in a Belgian summer and
 11:00 in winter. It is now read on the site's local clock, and the default moves
 to 19 so the drain runs into the evening and night rather than the solar day.
 
-Merges only after SAFETY-83 (peak guard outranks the drain at N=1): evening
-drains meet higher house loads.
+Evening drains meet higher house loads; SAFETY-83 (merged first) lets the
+peak guard outrank the drain.
 
 ## 1. Which zone
 
@@ -38,15 +38,24 @@ the settings stores every key (the reference install's blob has all 76). So
 almost every existing install keeps its stored 10, which now means 10:00 local
 instead of 12:00 (summer) or 11:00 (winter). Only a blob without the key gets 19.
 The add-on does not rewrite a stored option: a silent migration would override
-an operator's choice with no way to tell it apart from the old default. DOCS
-and the release note (drafted on the PR, for the version bump) tell the owner
-to set 19 if they want the evening start.
+an operator's choice with no way to tell it apart from the old default. A site
+that set an earlier hour to make up for UTC (17 for 19:00 summer) must set it
+back to 19 after the upgrade, or it starts two hours early. DOCS and the release
+note (drafted on the PR, for the version bump) say this.
 `tools/supervisor_shape_probe.py` §I measures this on Supervisor 2026.08.0.
 
-## 4. What does not change
+## 4. Two inverters
+
+`Controller` hands the same zone to every pack's `Maintenance`, so every pack's
+`wants_start()` reads the local hour. `arbitrate()` is unchanged: one pack
+cycles at a time, and the one that lost the slot starts in the first start
+slot after the other is done (a later day: a cycle outlasts its start hour). On the day the clocks go back, a pack freed during the second pass of
+a repeated hour does not start there. `test_maint10.py` part 10.
+
+## 5. What does not change
 
 Only the start decision (`Maintenance.wants_start`) and the Home screen's shown
-start time read the zone. `test_maint10.py` part 9 runs the real Controller
-with start hour 11 UTC against 13 Europe/Brussels (the same instant) and with
-12 UTC against 14 local (not the start hour): every command, claim, reason and
-log line is identical. A `Maintenance` built without a zone reads UTC, as before.
+start time read the zone. `test_maint10.py` parts 9 and 10 run the real
+Controller at N=1 and N=2 with start hour 11 UTC against 13 Europe/Brussels (the
+same instant): every command, claim, reason and log line is identical. A
+`Maintenance` built without a zone reads UTC, as before.