docs(series4): correct a sloppy count -- the conclusion holds, the evidence did not

The claim "THOR connections since 13:04:22 : 0" was an artifact of a time filter
(13:0[4-9]) that silently dropped everything from 13:10 onward.  THOR had in fact
connected four times, at 13:10:03-13:10:37.  Recorded rather than quietly fixed:
the number was stated as proven and it was wrong.

Inspecting those four connections shows the conclusion survives, for a better
reason than the one originally given.  They were user-initiated commands, not
polling:

    13:10:03  POLL -> SUB_96 (start monitoring)   13:10:05  MONITOR_STATUS
    13:10:35  POLL -> SUB_97 (stop monitoring)    13:10:37  MONITOR_STATUS

Single commands a human clicked, each followed by one status read.  Neither the
eleven-command status check nor the three-command connection check appears
anywhere in the window.

So automatic polling still has not resumed since 13:03:10 -- 16 minutes by
13:19:53 -- and every THOR connection in that window was operator-initiated:
the refresh at 13:04:21, then start and stop monitoring at 13:10.

Updates finding 3 from "three minutes of healthy link produced zero connection
attempts" to the stronger and now properly-evidenced "sixteen minutes produced no
AUTOMATIC attempts at all, only ones initiated by hand".

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

docs/micromate_protocol_reference.md

@@ -1800,8 +1800,9 @@ Before the fault THOR was connecting every 30 s without a miss for over an hour.
    backoff, no further attempts.
 2. **The automatic poll loop dies with it.**  Not just the download — the 30 s
    connection check and 60 s status check both stopped entirely.
-3. **It does not recover when the link returns.**  Three minutes of healthy link
-   produced zero connection attempts.
+3. **It does not recover when the link returns.**  Sixteen minutes of healthy
+   link produced **no automatic connection attempts at all** — only ones an
+   operator initiated by hand.
 4. **Refresh works, but only once.**  The manual check succeeded completely —
    all eleven commands, correct responses.  It did **not** restart the automatic
    loop; two minutes later there was still nothing.
@@ -1813,14 +1814,29 @@ that plainly fails, because the failure is *silent and looks like success*.
 
 ### 🔑 "Not polling" and "unreachable" are different states — and THOR conflates them
 
-Demonstrated directly.  At **13:10:44**, six and a half minutes after THOR's last
-connection of any kind:
+Demonstrated directly.  At **13:10:44** an independent `POLL` through the same
+relay succeeded with a correct response while THOR's automatic polling was dead.
+
+⚠ **A correction, recorded because the first version of this claim was sloppy.**
+It originally read "THOR connections since 13:04:22 : 0".  That count was an
+artifact of a time filter (`13:0[4-9]`) that silently dropped everything from
+13:10 onward.  THOR *had* connected four times, at 13:10:03–13:10:37.
+
+Inspecting those four shows the conclusion survives — but for a better reason
+than the one first given.  They were **user-initiated commands, not polling**:
 
 ```
-THOR connections since 13:04:22 : 0
-independent POLL through the same relay, same moment : succeeds, correct response
+13:10:03  POLL → SUB_96 (start monitoring)      13:10:05  MONITOR_STATUS
+13:10:35  POLL → SUB_97 (stop monitoring)       13:10:37  MONITOR_STATUS
 ```
 
+Single commands a human clicked, each followed by one status read.  Neither the
+eleven-command status check nor the three-command connection check appears.
+
+**Automatic polling did not resume**, and by 13:19:53 had been absent for
+**16 minutes**.  Every THOR connection in that window was something an operator
+clicked: the refresh at 13:04:21, then start and stop monitoring at 13:10.
+
 **The unit is reachable.  The link is fine.  THOR is simply not asking.**
 
 **THOR reports `Connection Status: Connected`.**  Captured at 13:15, eleven