docs(series4): Repeat is folded into Action -- and [6] is not the repeat flag

A capture that changed ONLY the Repeat Daily checkbox (pull schedule, disable
repeat, push schedule) moved exactly one byte in the entire session:

    record @0   Action  0x03 -> 0x02

Record 2 unchanged, [6] unchanged, and 0xDA / 0x68 / 0x82 / 0x71 / 0x94 / 0x8D all
byte-identical.

Two corrections to the previous commit:

  * [6] is NOT the repeat flag.  That was the field I predicted this capture would
    isolate; it stayed 2 and 16.  Still unidentified.
  * The label "Action" on [0] was too simple -- it carries repeat behaviour too.

Leading hypothesis: 2 and 3 are the two setup-bearing start actions the firmware
names, with repeat selecting between them --
    0 = DUTYCYCLE_CALLHOME
    2 = DUTYCYCLE_START_MONITOR_WITH_SETUP                 (repeat off)
    3 = DUTYCYCLE_START_MONITOR_WITH_SETUP_STOP_COMPLETE   (repeat on)

Supported independently by the THOR manual, which says a repeating schedule
hitting a Start Monitoring event while already monitoring will "stop the current
monitoring session, run any Auto Call Home actions, load the compliance setup and
continue monitoring" -- exactly what _STOP_COMPLETE should mean.  A repeating
start must terminate the in-progress session; a one-shot start need not.  The
firmware name, the manual's behaviour and the single moved byte all agree.

Explicitly NOT claiming the enum ordering: the action names were recovered with
`strings | sort`, so source order is lost.  Do not infer 1 = START_MONITOR just
because it falls between the two known values.  Three of six codes observed.

Also noted: Thor re-pushed the whole 2,090-byte config for a one-byte schedule
change -- a third instance of the schedule<->config coupling.

Capture provenance: the seismo_lab bins did not reach the dev box, but the socat
relay on mint-mac keeps its own timestamped -x log, and the session was
reconstructed from it byte-for-byte (25 frames each way, 0 bad checksums).  That
backup log is worth keeping in the loop -- it has now saved a capture once.

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

docs/micromate_protocol_reference.md

@@ -1546,9 +1546,52 @@ Action codes, so far:
 | `0` | **Auto Call Home** |
 | `3` | **Start monitoring, with setup** |
 
-⚠ `[6]` is the one field still unidentified — `2` on the start entry, `16` on the
+### The Repeat flag is folded into `Action` (2026-09-25)
-Auto Call Home entry.  It is not the name length and not the time.  A capture
+
-that changes only the **Repeat** checkbox, or switches Day↔Week, would isolate it.
+A capture that changed **only** the *Repeat Daily* checkbox — schedule pulled,
+repeat disabled, schedule pushed — moved **exactly one byte in the whole
+session**:
+
+```
+record @0   Action  0x03 → 0x02        (repeat ON → repeat OFF)
+```
+
+Nothing else moved.  Record 2 unchanged, `[6]` unchanged, and `0xDA`, `0x68`,
+`0x82`, `0x71`, `0x94`, `0x8D` all byte-identical.
+
+⚠ So **`[6]` is NOT the repeat flag** — the field predicted for that test is still
+unidentified.  And the earlier label on `[0]` was too simple: it is not a plain
+action index, it carries the repeat behaviour too.
+
+**Leading hypothesis** — `2` and `3` are the two *setup-bearing start* actions the
+firmware names, and repeat selects between them:
+
+| value | action | why |
+|---|---|---|
+| `0` | `DUTYCYCLE_CALLHOME` | the 19:30 entry, no setup name |
+| `2` | `DUTYCYCLE_START_MONITOR_WITH_SETUP` | repeat **off** |
+| `3` | `DUTYCYCLE_START_MONITOR_WITH_SETUP_STOP_COMPLETE` | repeat **on** |
+
+That reading is supported by the THOR manual's description of what a *repeating*
+schedule does on hitting a Start Monitoring event while already monitoring:
+
+> *"the unit will stop the current monitoring session, run any Auto Call Home
+> actions, load the compliance setup and continue monitoring."*
+
+Which is precisely what a name ending `_STOP_COMPLETE` would mean: a repeating
+start has to terminate the in-progress session first, a one-shot start does not.
+The firmware action name, the manual's behaviour, and the single byte that moved
+all agree.
+
+⚠ **The enum's ordering is NOT known.**  The action names were recovered with
+`strings | sort`, so their source order is lost — do **not** infer that `1` is
+`DUTYCYCLE_START_MONITOR` merely because it sits between the two known values,
+tempting as that is.  Three of six codes are observed (`0`, `2`, `3`); the
+remaining three need entries that use those actions.
+
+⚠ Note also that Thor re-pushed the **entire 2,090-byte config block** for a
+one-byte schedule change — a third instance of the coupling described in
+*The schedule↔config coupling is Thor's, not the protocol's*.
 
 ⚠ Also still unknown: whether the file can hold more than the records in use
 (both captures had every used record contiguous from offset 0), and the remaining