SAFETY-129 round 3: the real reason for the 16 s limit, a slow-start check, the row's tail

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

goodwe_controller/DECISIONS/SAFETY-128-late-readings.md

@@ -33,9 +33,10 @@ inverter limit in its last seconds (OPT-34 rig F-2).
      16 new values in 60 s, so only a meter of about 3.5 s or faster: at 5 s
      it gave false delays. Late over 8 s. At a slower meter (a 5 s P1) the
      same fit runs over 120 s and calls only a delay over 16 s late, on 2 fits
-     in a row, and never ends a verdict (SAFETY-129): a 10-12 s slow battery
-     reads up to 15 s there, so 10 s late is not told from it, and it does not
-     swing at 5 s.
+     in a row, and never ends a verdict (SAFETY-129). Alone it reads 35-90 s on healthy
+     runs, a few times in a row; only the slow-start and battery-fit check
+     below keeps those from a verdict. 10 s late is not found: it cannot be
+     told from a 10 s slow battery, and it does not swing at 5 s.
    - A meter fit says late only with evidence from the batteries' side too:
      a request more than 100 W from the battery reading took 3 s or more to
      move a reading towards it (`SLOW_START_S`; on time they start within
@@ -71,7 +72,9 @@ The fits run all the time; the pull request has the counts.
 - Found 36-68 s after a lag starts at 1-2 s meters; at a 5 s meter 30 s late
   is found within 100 s after it starts (88 s measured) (the loop first moves 100 W after 60 s,
   SAFETY-129) with the export above -200 W, and 10 s late is not found. Until
-  then control is as before.
+  then control is as before. In a quiet house the "readings late" row stays
+  about 2 minutes longer after the lag ends (126 s against 32 s on base); no
+  harm measured, and it clears as early as on base when the load changes.
 - A battery that answers slowly is read as late readings and held: a dead
   time of 10 s or more (8 s reads 7-8; 10 s reads 10 at 1-2 s meters, 9 at
   5 s), or a 15-20 s lag (review round 2). The GoodWe measured settles in 6 s