docs(series4): monitoring reads confirmed, and setup-name case is inconsistent

Two findings from a UM20147 run that was only meant to capture fixture bytes.

1. A MONITORING UNIT ANSWERS READS NORMALLY.  UM20147 was read while actively
   monitoring -- monitoring=True on both indicators, which agree -- and served
   POLL, serial, state, monitor status and a 5-entry setup walk with no special
   handling.

   This confirms the SESSION_RESET finding with our own client.  Series III
   REQUIRES a bare 41 03 before POLL or a monitoring unit will not answer over
   TCP.  That was inferred from its absence in THOR's captures; it is now
   demonstrated directly, on the other firmware line, by a client that never
   sends one.  (THOR's refusal to send a SETUP while monitoring is a write
   restriction -- reads are unaffected.)

   Monitoring moves two values, so neither is stable to compare against:
   battery drifted 3.55 -> 3.50 V and memory free 15,000,000 -> 14,848,448.

2. SETUP-NAME CASE IS NOT CONSISTENT BETWEEN COMMANDS.  Same unit, same
   session, same file: 0x41 reported "test2.MMB" and 0x40 reported
   "test2.mmb".  A run 45 minutes earlier reported "test2.mmb" from both, so it
   is not fixed per command either; what changed between is that the unit
   started monitoring.

   Cause is a guess from two samples.  The consequence does not depend on it:
   compare setup file names CASE-INSENSITIVELY.  An exact-string test of "is
   the active setup one I know about?" answers no on this unit.  Worth fixing
   before it is a field bug, since name matching is on the path for anything
   that replaces THOR's setup/scheduler coupling.

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

docs/micromate_protocol_reference.md

@@ -879,6 +879,46 @@ active setup `test2.mmb`, 15,000,000 bytes total and free. 21 reads, 2,165 B in.
 headline finding of 2026-09-23 — is now demonstrated by a working client, not
 just by matching response SUBs.
 
+### ✅ A MONITORING unit answers reads normally (2026-09-30)
+
+UM20147 was read while actively monitoring — `monitoring=True` on **both**
+indicators (`0x49` content[0] and `0x1C` content[1], which agree) — and
+answered POLL, serial, state, monitor status and a 5-entry setup walk with no
+special handling.
+
+**This confirms the `SESSION_RESET` finding with our own client.** Series III
+*requires* a bare `41 03` before POLL or a monitoring unit will not answer over
+TCP. That was previously inferred from its absence in THOR's captures; it is now
+demonstrated directly, on the other firmware line, by a client that never sends
+one.
+
+Note THOR *refuses to send a setup* to a monitoring unit — that restriction is
+about writes. Reads are unaffected.
+
+Monitoring also moves two values, so neither is a stable thing to compare
+against: battery drifted 3.55 → 3.50 V, and memory free dropped 15,000,000 →
+14,848,448 (monitoring allocates as it runs).
+
+### ⚠ Setup-name case is NOT consistent between `0x41` and `0x40`
+
+Same unit, same session, same file:
+
+```
+0x41  active setup name  ->  test2.MMB
+0x40  setup-list entry   ->  test2.mmb
+```
+
+An earlier run 45 minutes before reported `test2.mmb` from *both*, so the case
+is not fixed per command either. What changed in between is that the unit
+started monitoring — plausibly it rewrites the active-setup name in a canonical
+form when loading a setup, but that is a guess from two samples.
+
+**Practical consequence, which does not depend on the cause: compare setup file
+names case-insensitively.** An exact-string test of "is the active setup one I
+know about?" answers *no* on this unit. Worth fixing before it is a field bug —
+Thor's own UI couples the scheduler to a setup name, so name matching is on the
+path for anything that replaces it.
+
 ### Still not covered
 
 - **A download from a BD unit.** UM20147 had no events stored, so the chunk