SAFETY-44: the latch migration takes the roster, and the guard stops being defeated by the key the defect wrote

⚠️ A DISARMED SAFETY-02 GUARD ON AN INSTALL WHOSE STATE FILE SAYS IT IS
PROTECTED. `Controller.__init__` called `migrate_unit_keys(store, UNIT_A)` - a
hardcoded constant - while its sibling `migrate_maint_keys(store, unit, roster)`
takes the roster and refuses a write no machine reads. On a store that ran
pre-DEV-02 flat and declares `inverters: [garage, shed]`, the latch moved to
`unit/inverter-a/sign_tripped`, `_verify_moves()` read it back under the name it
had been HANDED, was satisfied, and stamped the marker. Not one inverter came up
latched, and the next start skipped the migration too.

That is the MAINT-05 defect verbatim, still live in the function whose own
docstring describes it, and `_grade_store_migration()` did not catch it: its
"is anything namespaced latched" test was satisfied BY THE MISDIRECTED VALUE
ITSELF.

⚠️ THE REASON IT WAS LEFT WAS A HALF-TRUTH. "There is no roster yet - the
`Inverter`s restore their latch in their constructors." The KEYS must be written
before the `Inverter`s read them; the NAMES do not come from the `Inverter`s.
`roster_names(opts)` reads them off the options before anything is constructed -
which is exactly what it already existed to do for `MqttPublisher` - and returns
`[UNIT_A]` on the flat shape, so today's upgrade path is byte-identical.

TWO EDITS, AND THEY DO DIFFERENT JOBS. Measured per leg by reverting each one:

                          SAME-STEP leg          STAGED leg
  both edits (shipped)    clean                  latch armed, litter reported
  guard reverted          latch armed            ⚠️ DISARMED
  call site reverted      latch armed, litter    latch armed, litter

So the GUARD carries the safety and the CALL SITE carries the hygiene and the
withheld marker. The table is in test_rehearse.py part 5 because a reader who
assumed the roster-aware migration re-arms the latch would delete the guard as
redundant in a tidy-up and take the STAGED column with it - and STAGED is what
"upgrade now, declare the roster later" produces, which is the path an operator
actually takes. Only the guard reaches an install already stamped by 0.9.0.

⚠️ AND "OFF THE ROSTER" ALONE WAS TOO BLUNT, WHICH test_inverter.py CAUGHT. The
first draft treated every off-roster latch as litter. In DEV-02's restart case
the store carries `unit/inverter-b/sign_tripped = True` from B's own trip while
the roster being graded holds only A - and the blunt rule re-armed a HEALTHY A
off the flat key B's trip had mirrored. DEV-02's defect rebuilt inside its own
guard, which is what the paragraph I was overruling had been right to fear.

Narrowed to `UNIT_A`, which is the only name the broken migration ever wrote -
`roster_names()` falls back to a POSITIONAL `inverter-N`, so `inverter-a` is not
a name this code hands to anyone else. A latch stranded under any other name is
a real unit out of today's config and still counts as protection. Residual,
stated in the code rather than left to be found: a site whose own first unit is
NAMED `inverter-a`, latched, then taken out of the roster gets re-armed on
`inverters[0]` - a healthy unit held at 0 W until an operator clears it. The
conservative direction, against a site DRIVING on a file that says it is latched.

⭐ AND FIXING THE CODE EXPOSED A FALSE POSITIVE IN THE HARNESS. With the latch
now landing under `garage`, `rehearse_roster.py` reported VANISHED STORE KEY for
`unit/inverter-a/sign_tripped` three lines above the same value sitting under
`unit/garage/sign_tripped`. A key that moved to a namespace a machine reads has
not vanished - and an alarm that fires on the harmless case is one an operator
learns to dismiss before the real one arrives, which is CONTROL-C's own
argument. The test is not "the name appears somewhere": same bare key, same
value, under a key in `machine_read`, the set built by driving a real start. A
latch that genuinely went missing has no such key and is still a finding, which
M3 (delete the flat rollback view) still measures red.

Test parts replaced deliberately, as both of them asked to be:
  - test_rehearse.py part 5 asserted the defect "as REQUIREMENTS so that a fix
    turns them red". It now asserts the fix, with 5b and 5c as negative controls
    - one per edit - and 5b doubles as the leg-splitter's positive control,
    since reverting the guard is the build where the two legs DISAGREE.
  - test_maintenance.py section 13 was headed "RECORDED, NOT FIXED" and said the
    fixing card "should expect them to go red and should replace them". Replaced,
    plus two cases it could not have had: the already-stamped store, and the
    `inverter-b` negative control for the narrowing above.

28/28 files pass. Not run: nothing - this is host-side only, no rig, no hardware.

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

goodwe_controller/tools/rehearse_roster.py

@@ -460,6 +460,7 @@ class Snapshot:
         # finding: see `diff()`.
         self.stranded_at_default = []
         self.vanished_at_default = []
+        self.vanished_but_migrated = []
 
     @property
     def unit_keys(self):
@@ -550,6 +551,29 @@ def diff(before: Snapshot, after: Snapshot) -> list:
         if value in (None, DEFAULTS.get(bare)):
             after.vanished_at_default.append(f"{key} = {value!r}")
             continue
+        # ⚠️ AND A KEY THAT MOVED TO A NAMESPACE A MACHINE READS HAS NOT
+        # VANISHED, WHICH IS THE SAME CORRECTION ONE PARAGRAPH UP, ONE CARD
+        # LATER. SAFETY-44's fix made `migrate_unit_keys()` write under the
+        # ROSTER's first name instead of the hardcoded `inverter-a`, so on a
+        # renamed roster the before-snapshot holds `unit/inverter-a/
+        # sign_tripped = True` and the after-snapshot holds
+        # `unit/garage/sign_tripped = True`. Measured on that build: two
+        # VANISHED findings for a LATCH THAT IS SITTING ON THE SAME PAGE OF THE
+        # REPORT, three lines above them, under the name the roster reads.
+        #
+        # ⚠️ THE TEST IS NOT "the name appears somewhere". It is: the SAME bare
+        # key, at the SAME value, under a key in `machine_read` - the set built
+        # by driving a real start, not by pattern-matching a namespace. A latch
+        # that genuinely went missing has no such key and is still a finding,
+        # which is what M3 (delete the flat rollback view) measures and what
+        # keeps this from being a softening of the check.
+        moved_to = sorted(
+            k for k in after.machine_read
+            if k.rsplit("/", 1)[-1] == bare and after.data.get(k) == value)
+        if key.startswith("unit/") and moved_to:
+            after.vanished_but_migrated.append(
+                f"{key} = {value!r} -> {moved_to[0]}")
+            continue
         findings.append(Finding(
             "VANISHED STORE KEY",
             f"{key} = {value!r} was in the store before the "
@@ -846,6 +870,15 @@ def report_transition(leg_id, name, before, after, findings) -> None:
         mark = "  " if key in after.data else "  (absent, defaulted) "
         print(f"      {key}{mark}")
 
+    if after.vanished_but_migrated:
+        print()
+        print("    keys that MOVED to the namespace this roster reads - not "
+              "lost, and shown")
+        print("    because a rename that relocates a LATCH is the operator's "
+              "business:")
+        for text in after.vanished_but_migrated:
+            print(f"      migrated  {text}")
+
     if after.stranded_at_default or after.vanished_at_default:
         print()
         print("    keys whose value IS the default `Store.load()` supplies, so "