docs(series4): the schedule<->config coupling is Thor's, not the protocol's

In Thor, a schedule entry that starts monitoring forces you to attach a setup,
and sending the schedule pushes that setup too, overwriting anything with the
same name.  The protocol requires none of it.

Evidence from the scheduler capture:

  * The two writes are separate operations, not one transaction.  The config
    write ends at frame 18, Thor sends a fresh POLL preamble, and only then opens
    the schedule at frame 20.  Different commands, different paths:
        config    0xDA -> 0x68/0x73 -> 0x82/0x83 -> 0x71/0x72
        schedule  0x8D -> 0x8E
  * The schedule stores a length-prefixed NAME, not a config blob.  It is a
    reference, and a reference does not require rewriting its referent.
  * The config Thor pushed was already on the unit unchanged -- its 2,090-byte
    0x71 payload is byte-identical to the previous capture's, zero differences.
    Thor spent a whole block write re-sending a setup the device already had.

So SFM can, with today's protocol: enumerate setups with 0x3F/0x40, write ONLY
the schedule when the referenced setup already exists, and push a config only
when it is genuinely missing or deliberately edited.  Common case drops from
524 + 2090 bytes to 524, and the write disappears entirely.

It also removes a real hazard.  Because the reference is by name, and a same-name
write overwrites silently with an indistinguishable ack, Thor's pattern means
scheduling something can quietly rewrite a setup that other schedules or the
operator's own work depend on.  Validating the reference instead of rewriting the
referent avoids the class of problem.

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

docs/micromate_protocol_reference.md

@@ -1322,6 +1322,55 @@ checked whether the unit cares."
 | Greys out send-to-unit while monitoring | **Thor policy** | The *reason* is real — a push to the active setup overwrites silently.  But "the button is grey and you figure it out" is a UX choice, not the only answer.  SFM could offer stop → push → restart as one operation, which is what an operator actually wants. |
 | Names the target with `0xDA` before a config write | **almost certainly required** | The unit has to know which file to write.  Closest thing here to a genuine protocol requirement. |
 
+### The schedule↔config coupling is Thor's, not the protocol's
+
+In Thor, putting "start monitoring" in a schedule forces you to attach a setup,
+and sending the schedule pushes that setup at the same time — overwriting
+whatever already has that name.  **The protocol does not require any of this.**
+
+The evidence, from the scheduler capture:
+
+- **The two writes are separate operations**, not one transaction.  The config
+  write ends at frame 18 (`0x72`), then Thor sends a fresh `POLL` preamble, and
+  only then opens the schedule for writing at frame 20.  Different commands,
+  different paths, no shared state:
+
+  ```
+  config    0xDA → 0x68/0x73 → 0x82/0x83 → 0x71/0x72
+  schedule  0x8D → 0x8E
+  ```
+
+- **The schedule stores a NAME, not a config.**  A length-prefixed filename is
+  all an entry carries.  It is a *reference*, and references do not require the
+  referent to be rewritten.
+
+- **The config Thor pushed was already on the unit, unchanged.**  Its 2,090-byte
+  `0x71` payload is **byte-identical** to the previous capture's — zero
+  differences.  Thor spent a full block write re-sending a setup the device
+  already had, purely to satisfy its own coupling.
+
+So the sequencing is a Thor UI decision, and a costly one.
+
+**What SFM can do instead, with today's protocol and nothing new:**
+
+1. Enumerate the unit's setups with `0x3F` / `0x40` — cheap, read-only, and it
+   yields the exact names a schedule may legally reference.
+2. Write **only** the schedule (`0x8D` / `0x8E`) when the referenced setup is
+   already present.
+3. Push a config only when it is actually missing, or when the operator
+   deliberately edited it — and say so explicitly rather than silently.
+
+That removes the write entirely from the common case: scheduling against a setup
+that already exists becomes a 524-byte schedule write instead of 524 bytes plus
+a 2,090-byte config overwrite.
+
+⚠ **And it removes a real hazard.**  Because the reference is by name, and
+because a same-name write overwrites silently with an indistinguishable ack,
+Thor's pattern means *scheduling* something can quietly rewrite a setup that
+other schedules — or the operator's own saved work — depend on.  Nothing in the
+protocol or the ack reports that this happened.  Validating the reference
+instead of rewriting the referent avoids the whole class of problem.
+
 ### What this implies for the build order
 
 The read path is fully known and needs no Thor-shaped decisions, so a read-only