SAFETY-02: the P_PEAK assertion was pinning the test's copy of the gate

Review finding 2, and it is the same duplication `disagrees()` just removed, so
it gets the same fix rather than a follow-up card.

`following_from()` in test_watchdog.py was a TRANSCRIPTION of the gate in
main.py, carrying "keep the two in step" as an instruction - which is exactly the
arrangement that does not keep two things in step. Measured: editing the shipped
gate alone to `winner in ("loop", "peak")` left every suite green while the
watchdog went blind for the duration of every peak event. The row whose whole job
is to force whoever lands peak shaving to come and change an expectation did not
do that.

The expression is now `watchdog.loop_is_following()`, called by main.py and by
the test. One definition, two callers, same reasoning as `disagrees()`: the copy
that drifts is always the one in the harness doing the grading.

⚠️ AND EXTRACTING IT WAS NOT SUFFICIENT - the drift proof still came out green
after the extraction, which is why it was worth running rather than assuming. The
realistic P_PEAK row has peak shaving asking for MORE than the loop, so the
magnitude term rejects it whatever `winner` says and masks the term under test. A
second row with peak asking for LESS makes `winner` the only deciding term. With
that row, widening the shipped gate fails two checks; without it, none.

Also enforcing the write ordering that was documented and not asserted: swapping
the two `store.set` calls passed everything. A store that fails the second write
now proves the property the ordering exists for - a crash mid-trip leaves a
reason with no latch, never a latch with no explanation. Swapping them now turns
that check red.

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

goodwe_controller/app/main.py

@@ -41,7 +41,7 @@ from .maintenance import IDLE, MaintConfig, Maintenance
 from .mqtt import MqttPublisher
 from .p1 import P1Ingest, build_source, is_enabled
 from .validate import ConfigRefused, refuse, validate_startup_config
-from .watchdog import SignWatchdog, SignWatchdogConfig
+from .watchdog import SignWatchdog, SignWatchdogConfig, loop_is_following
 from . import web
 
 OPTIONS_PATH = "/data/options.json"
@@ -378,43 +378,17 @@ class Controller:
         # --- SAFETY-02's arming gate ------------------------------------------
         # Was the number about to go on the wire chosen by the grid-following
         # loop, or by a strategy that commands against the meter on purpose?
-        # Only the former is expected to agree in sign with P1. See gate 1 in
-        # watchdog.py - without this, every maintenance grid charge trips the
-        # failsafe within three minutes of starting.
+        # Only the former is expected to agree in sign with P1 - without this,
+        # every maintenance grid charge trips the failsafe within three minutes.
         #
-        # ⚠️ "THE LOOP WON" IS NOT ENOUGH, and the difference is a whole class of
-        # false trip. A LIMIT claim can survive the loop winning and still
-        # replace its number: maintenance's cheap-window shaping is
-        # `hi = -maintenance_charge_w`, so with `maintenance_charge_w: 1500` the
-        # loop can ask for +500 W of discharge, win the arbitration, and have the
-        # emitted value come out at -1500 W of grid charge. Winner says "loop";
-        # the wire carries maintenance's intent. So the test is on the NUMBER,
-        # not on the name: the loop is following only while the emitted value
-        # points the way the loop asked and is no larger than it asked - i.e.
-        # limits reduced it, they did not redirect it. Zero on either side falls
-        # out as not-following, which costs nothing: a 0 W command cannot be a
-        # wrong-direction command. The `abs(...) <= abs(asked)` half is
-        # load-bearing on its own: a `lo` limit can raise the magnitude without
-        # flipping the sign, and that is not the loop following either.
-        #
-        # (1500 W because at the SHIPPED defaults - maintenance_charge_w 2500 vs
-        # max_w 2000 - that claim is `lo=-2000 > hi=-2500`, which the arbiter
-        # calls a contradiction and resolves to 0 W. Filed separately; the
-        # redirect hazard here is real at any charge rate inside max_w.)
-        #
-        # ⚠️ FORWARD HAZARD, AND IT IS NOT HYPOTHETICAL - the claim block above
-        # already anticipates it. `winner == "loop"` disarms this watchdog under
-        # ANY higher-priority SET claim. Today only maintenance and the safety
-        # stops emit one, and neither is grid-following, so the gate costs
-        # nothing. A peak-shaving strategy claiming SET at P_PEAK **is**
-        # grid-following in sign, and the moment it lands this watchdog goes
-        # blind for the duration of every peak event. Whoever adds it must widen
-        # the gate to "the winning strategy follows the meter" rather than
-        # "the winner is the loop", not just add another name to a comparison.
-        asked = self.loop_w
-        self.following = (resolution.winner == "loop" and asked is not None
-                          and resolution.target_w * asked > 0
-                          and abs(resolution.target_w) <= abs(asked))
+        # ⚠️ THE EXPRESSION LIVES IN watchdog.py, NOT HERE, and that is not
+        # tidiness. It was inline, test_watchdog.py held a transcription of it,
+        # and the P_PEAK case meant to force whoever lands peak shaving to come
+        # and change an expectation did not: editing this line alone to
+        # `winner in ("loop", "peak")` left every suite green while the watchdog
+        # went blind for every peak event. Read loop_is_following() before
+        # touching the gate - the forward hazard and the reasoning are there.
+        self.following = loop_is_following(resolution, self.loop_w)
         self.target = resolution.target_w
         self.reason = resolution.explain()
         await self.write_setpoint(self.target)