docs(series4): the schedule has a setup-less start action -- Thor never uses it

The schedule<->config coupling looked like it might be a workaround for the unit
crashing on a missing setup.  The firmware says otherwise: there are two distinct
start-monitoring actions in the scheduler's duty-cycle dispatch, and only one
involves a setup file.

    _PSA() case DUTYCYCLE_START_MONITOR
    _PSA() case DUTYCYCLE_START_MONITOR_WITH_SETUP

Full action set: START_MONITOR, START_MONITOR_WITH_SETUP, STOP_MONITOR,
CALLHOME, SELF_CHECK, plus ON/OFF/NEXT for scheduler state.

So the coupling is not a crash workaround -- Thor picks the more demanding of two
available actions every time.  SFM can emit START_MONITOR and skip the config.

On whether a missing setup would actually break the unit: the firmware suggests
graceful degradation (`Setup File Not Found`, and `Invalid parameters reset to
factory default - please review setup`, a deliberate fallback).  Untested, and
recorded as untested.

Hypothesis, flagged as such: the schedule entry's leading byte may be the action
code -- the one captured entry reads `03 00 00 00 0f 03 02 [namelen][name]` and
03 would fit START_MONITOR_WITH_SETUP.  One entry, nothing to diff, unverified.

Names the capture that would settle it, and which is worth more than the 0x47
disable/enable test: a schedule entry with a setup-less action (stop monitoring,
or call home).  It would confirm or kill the action-code hypothesis and prove
from the other direction that a schedule needs no config push.

Also noted: DUTYCYCLE_CALLHOME -> CMD_SCHEDULE_CALL_HOME means a scheduled
call-home can make a unit dial out on demand -- the one remaining lever on the
unsolved call-home direction.

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

docs/micromate_protocol_reference.md

@@ -1371,6 +1371,53 @@ other schedules — or the operator's own saved work — depend on.  Nothing in
 protocol or the ack reports that this happened.  Validating the reference
 instead of rewriting the referent avoids the whole class of problem.
 
+#### The schedule has a setup-less start action — Thor just never uses it
+
+The coupling above looked like it might be a workaround for the unit crashing on
+a missing setup.  The firmware says otherwise: **there are two distinct
+start-monitoring actions**, and only one of them involves a setup file.
+
+```
+_PSA() case DUTYCYCLE_START_MONITOR
+_PSA() case DUTYCYCLE_START_MONITOR_WITH_SETUP
+```
+
+The full duty-cycle action set, from the scheduler task's own dispatch strings:
+
+| action | notes |
+|---|---|
+| `DUTYCYCLE_START_MONITOR` | **no setup involved** — uses whatever config is loaded |
+| `DUTYCYCLE_START_MONITOR_WITH_SETUP` | the variant Thor always emits |
+| `DUTYCYCLE_STOP_MONITOR` | |
+| `DUTYCYCLE_CALLHOME` | `send ==> CMD_SCHEDULE_CALL_HOME` |
+| `DUTYCYCLE_SELF_CHECK` | `call DailySelfCheck()` |
+| `DUTYCYCLE_ON` / `OFF` / `NEXT` | scheduler state, not per-entry actions |
+
+So the schedule↔config coupling is not a crash workaround — **Thor picks the more
+demanding of two available actions, every time.**  SFM can emit
+`START_MONITOR` and skip the config entirely.
+
+On whether a missing setup *would* break the unit: the firmware suggests
+graceful degradation rather than a crash — `Setup File Not Found` exists, and so
+does `Invalid parameters reset to factory default - please review setup`, which
+is a deliberate fallback.  ⚠ **Untested**, and not worth relying on until it is.
+
+⚠ **Hypothesis, not a finding:** the schedule entry's leading byte may be the
+action code — the one captured entry reads `03 00 00 00 0f 03 02 [namelen]
+[name]`, and `03` would fit `START_MONITOR_WITH_SETUP` in an enum of the above.
+Unverified; there is one entry and nothing to diff against.
+
+**The capture that would settle it** (more valuable than the `0x47`
+disable/enable test): build a schedule whose entry is **stop monitoring** or
+**call home** — an action with no setup attached.  That would (a) confirm or kill
+the action-code hypothesis, since a setup-less action should change the leading
+byte and drop the name, and (b) prove from the other direction that a schedule
+can be sent with no config push at all.
+
+Note also `DUTYCYCLE_CALLHOME` → `CMD_SCHEDULE_CALL_HOME`: **a scheduled
+call-home is a way to make a unit dial out on demand**, which is the one
+remaining lever on the unsolved call-home direction.
+
 ### What this implies for the build order
 
 The read path is fully known and needs no Thor-shaped decisions, so a read-only