docs(series4): REFUTE the half-period theory -- the connection dial sets a count

The prediction was sharp and it was wrong.  I hypothesised the connection check
ran at half the status period, predicting 30 s when status is set to 60 s.
Measured: 60.5 s.  Recorded rather than quietly deleted.

Three configurations now measured, each over many cycles:

    status 10 / conn 10  ->  status 10.1 s    conn: none ever ran      0 per cycle
    status 30 / conn 10  ->  status 30.4 s    conn 15.2 s              2 per cycle
    status 60 / conn 30  ->  status 60.5 s    conn 60.5 s              1 per cycle

The status dial is honoured in all three, within ~1%.  The connection dial is
honoured in none.  What holds across all three is a count, not a period:

    separate connection checks per status cycle = (status / connection) - 1

Consequences: setting the two dials equal yields ZERO connection checks, so every
connection is the expensive eleven-command status read -- and that is the
configuration that looks like the default.  "Every 30 s" with status at 60 s
gives one check per minute, half the advertised rate.  No simple scale factor
describes the observed cadences either (10 -> 15.2, 30 -> 60.5).

Still unexplained: the phase within a cycle.  At status 30 / conn 10 the two short
checks landed at T+10.1 and T+25.3 where an evenly divided cycle would put them at
T+10 and T+20.  The count rule holds; the phase does not follow from it.

Also adds a traffic table across the three configurations: 563 MB/month at
10 s/10 s, 147 MB/month at the current 60 s/30 s, against 9 MB/month for a
POLL + MONITOR_STATUS check at 60 s.

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

docs/micromate_protocol_reference.md

@@ -1669,14 +1669,62 @@ FULL    at T + 30.4      (+5.1)
 27 consecutive connection-check gaps, all 15.1–15.3 s.  That is systematic, not
 jitter.
 
-**15.2 s is exactly half of 30.4 s**, and the two are phase-locked 2:1 — which
-suggests the connection check is not running on its own setting at all, but at
-half the *status* period.
+> ⚠ **A "half the status period" hypothesis was raised here and REFUTED.**  It
+> predicted that with status at 60 s the connection check would run at 30 s.
+> Measured: **60.5 s**.  Recorded rather than deleted — the prediction was sharp
+> and it was wrong.
 
-⚠ **Hypothesis, not established.**  It predicts sharply: with status at 60 s the
-connection check should land at 30 s **whatever its dial says**.  One capture
-settles it, and it is worth settling before SFM offers any similar control — a
-dial that silently does nothing is worse than no dial.
+### The connection dial sets a COUNT, not a period
+
+Three configurations, each measured over many cycles:
+
+| status | connection | status observed | connection observed | separate conn checks per status cycle |
+|---|---|---|---|---|
+| 10 s | 10 s | 10.1 s ✅ | — | **0** (none ever ran) |
+| 30 s | 10 s | 30.4 s ✅ | 15.2 s ❌ | **2** |
+| 60 s | 30 s | 60.5 s ✅ | 60.5 s ❌ | **1** |
+
+**The status dial is honoured in all three** — within about 1%.
+
+**The connection dial is not honoured in any of them.**  What actually holds is:
+
+```
+separate connection checks per status cycle  =  (status ÷ connection) − 1
+```
+
+1 → 0 checks, 3 → 2 checks, 2 → 1 check.  So the field does not set a period; it
+sets how many checks fit inside a status cycle, and it is off by one.
+
+Consequences worth naming:
+
+- **Setting the two dials equal yields zero connection checks.**  Every
+  connection is then the expensive eleven-command status check.  That is the
+  default-looking configuration, and it is the worst one.
+- **"Every 30 s" with status at 60 s gives one check per minute** — half the
+  advertised rate.
+- The observed cadences are not multiples of the connection setting at all
+  (10 s → 15.2 s; 30 s → 60.5 s), so no simple scale factor describes it either.
+
+⚠ The *timing within* a cycle is still not fully explained.  At status 30 /
+connection 10 the two short checks landed at T+10.1 and T+25.3, where an evenly
+divided cycle would put them at T+10 and T+20.  The count rule holds across all
+three configurations; the phase does not follow from it.
+
+**For SFM:** this is the concrete argument against exposing a dial whose
+behaviour is not what it says.  If a control sets an interval, it should set that
+interval — and if the effective rate is derived from something else, the UI
+should show the derived value, not the input.
+
+### Traffic at each configuration
+
+| status / connection | per minute | per day | per month |
+|---|---|---|---|
+| 10 s / 10 s | ~13 KB | **18.8 MB** | **563 MB** |
+| 60 s / 30 s (current) | ~3.4 KB | **4.9 MB** | **147 MB** |
+| a minimal check at 60 s | ~0.2 KB | **0.3 MB** | **9 MB** |
+
+The last row is `POLL` + `MONITOR_STATUS` only — enough to answer "alive?" and
+"monitoring?".
 
 ### ⚠ What this means for the "won't stay connected" failure