verify(micromate): 11.0BD confirmed on hardware -- every inference held

UM20147 read over USB by mm_client_check.py.  The Thor firmware line was
entirely inference until now, and two of its three differences were covered
only by SYNTHESISED test frames.  All three held:

- flags = 0x03 identifies the line -> reported firmware_line="thor".  That is
  only reachable if `10 03` in the flags position destuffs before indexing,
  since 0x03 is ETX -- so the escaped-flags case is confirmed too.
- the model string is shorter -> reported "MM/ISEE/S" exactly.  Anchoring the
  search on b"MM/" rather than a fixed span is what made this work.
- the 0x1C block is 4 bytes longer with the extras TRAILING, so from-the-start
  offsets survive -> battery 3.55 V and a clock correct to the second.

That last one is the one that mattered.  Series III's from-the-end offsets
would have given this unit 577.92 V, which is why mm_client_check watches for
an impossible voltage: it is a free self-check on exactly the inference most
likely to be wrong.

Also clean: serial UM20147, 5 setups (factory.MMB -> test2.mmb), active setup
test2.mmb, 15,000,000 B total and free, 21 reads / 2,165 B in.

"One protocol stack drives the whole fleet regardless of firmware line" -- the
headline finding of 2026-09-23 -- is now demonstrated by a working client
rather than by matching response SUBs.

Test and docstring claims downgraded from inference to confirmed where the
hardware settled them, and left as synthesised-frame notes where it did not:
the BEHAVIOUR is confirmed but raw BD bytes are still not in the repo.

Added --capture DIR to mm_client_check: writes a raw_bw_*/raw_s3_* pair in the
layout scratch/mm_frame_parse.py already reads, so a run on an unfamiliar unit
becomes a test fixture without setting up a relay.  Verified by round-tripping
its own output through that parser: 28 frames, 0 bad checksums.

Still not covered: a download from a BD unit (UM20147 had no events stored, so
the chunk walk remains CB-only), raw BD fixture bytes, a monitoring unit, a
nearly-full buffer, and the inbound call-home session.

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

docs/micromate_protocol_reference.md

@@ -854,11 +854,41 @@ captured `0x5A` responses and fed to `micromate.idf_file.read_idf_file()`:
 `thor-watcher` forwards today, so `/db/import/idf_file` ingests a directly
 downloaded event unchanged.
 
+### ✅ `11.0BD` confirmed on real hardware (2026-09-30)
+
+UM20147 read over USB. **Every inference about the Thor firmware line held**,
+and two of the three were covered only by *synthesised* test frames until now:
+
+| inference | predicted | UM20147 reported |
+|---|---|---|
+| `flags = 0x03` identifies the line | `thor` | ✅ `thor` |
+| `0x03` is ETX, so it arrives as `10 03` | destuffs before indexing | ✅ implied — the line could not be identified otherwise |
+| model string is shorter | `MM/ISEE/S` | ✅ `MM/ISEE/S` |
+| `0x1C` is 4 bytes longer, extras **trailing** | forward offsets survive | ✅ battery **3.55 V**, clock correct to the second |
+
+That last row is the one that mattered. Series III's from-the-end offsets would
+have produced **577.92 V** on this unit — a number so obviously wrong it is a
+cheap self-check, which is why `mm_client_check.py` watches for it. Reading a
+plausible 3.55 V and a correct clock confirms the four extra bytes really are
+trailing.
+
+Also read cleanly: serial `UM20147`, 5 setups (`factory.MMB` → `test2.mmb`),
+active setup `test2.mmb`, 15,000,000 bytes total and free. 21 reads, 2,165 B in.
+
+**One protocol stack drives the whole fleet regardless of firmware line** — the
+headline finding of 2026-09-23 — is now demonstrated by a working client, not
+just by matching response SUBs.
+
 ### Still not covered
 
-- **`11.0BD`** — UM12947 is a `11.0CB` unit. The Thor firmware line is still
-  entirely inference: `flags = 0x03`, a shorter model string, and a `0x1C`
-  block 4 bytes longer. `mm_client_check.py` says so loudly when it meets one.
+- **A download from a BD unit.** UM20147 had no events stored, so the chunk
+  walk is verified on `11.0CB` only. Nothing suggests it differs — the `0x5A`
+  prefix and the offset arithmetic are not firmware-line dependent in anything
+  observed — but it is untested.
+- **Raw BD bytes are still not in the repo.** The behaviour is confirmed; the
+  test fixtures for the Thor line remain synthesised. `mm_client_check.py
+  --capture DIR` now writes a `raw_bw_*`/`raw_s3_*` pair in the layout
+  `scratch/mm_frame_parse.py` reads, so one more run on UM20147 would close it.
 - **A unit that is monitoring**, and a unit with a nearly-full event buffer.
 - **The inbound call-home session** — still the one protocol unknown.