feat: the locked trigger pane carries Arm/Disarm, and one function states both arm buttons

The compact line -- the pane's locked, "what is it set to" mode -- showed the arm state in words and gave
no way to change it, so arming from there meant unfolding the panel first, which is the thing the lock
exists to avoid. The control is built into the pane's *heading*, the row that stays on screen when the
body goes, and it is wired to the same `on_arm_clicked` the body's button uses, so both do one thing.

Its label, sensitivity and visibility are stated by `sync_arm_buttons()`, called from the four places any of
its inputs can move: the click, the mode toggle, the curator's per-tick re-read (a single-shot latch disarms
by itself) and `apply_pane_lock()`. The label comes from the producer's `trigger_armed()` atomic, the other
two from the toolbar toggle that owns `enabled`, so no caller needs the model lock. Visibility is
`enabled && locked`: with trigger mode off the line beside it already reads "stream (trigger off)" and there
is no engine to arm, and with the pane open the body's own button is the one on screen. Never both -- two
arm buttons would be two controls for one state.

Verified with the arm probe, which locks the pane the way a user does (the [edit] click):

    compact arm with the trigger off: visible=0; with the trigger on and the pane locked:
      visible=1 sensitive=1 width=51 label=Disarm
    [udpscope] compact arm probe: locked=1 enabled=1 own=1 effective=1 width=51 panel_width=-1 label=Disarm

`panel_width=-1` is the "not both" assertion: the body's button is not on screen while the compact one is.
The width cost a defect to read. The control is created hidden and shown for the first time inside the
handler, so a same-tick `gtk_widget_get_width()` reads 0 while `gtk_widget_is_visible()` already says 1 --
and the body button's *stale* allocation (270 px, from when the body was still up) reads as a live one,
because `gtk_widget_get_visible()` is the widget's own flag and stays true under a hidden parent. The
reading is therefore taken one frame later, by a step of its own, and the control is compared with
`is_visible()`. Both defects are in the invariants, because the next control read this way will meet them.

0 Gtk-CRITICAL; clean build with the documented four warnings (the help resource re-measured); test-ui
14/14. Docs: the rule and both readings in `invariants-trigger-and-pinning.md`, the probe's entry in
`probe-readings.md`, and the user-facing sentence in `src/help/08-trigger.txt`.

docs/claude/invariants-trigger-and-pinning.md

@@ -18,6 +18,23 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   reports it as `zoom ... span=.. window=.. limited=1`.
   Its pan clamping is likewise gated on the data being wider than the view, or the empty
   left-hand side drags the live edge off the right-hand edge.
+- **The compact pane's arm control is built in the heading, and *one* function states both arm
+  buttons.** Arming is a runtime decision and the locked pane is exactly where it is made, so the
+  control cannot live in the body — that is the part which goes away. `sync_arm_buttons()` is what
+  states the label, the sensitivity and the visibility of both buttons, and it is called from the four
+  places any of its three inputs can change (the click, the toolbar toggle, the curator's re-read,
+  `apply_pane_lock()`). Visibility is `enabled && locked`: with trigger mode off the line beside it
+  already says "stream (trigger off)" and there is no engine to arm, and with the pane open the body's
+  button is the one on screen — **two arm buttons at once would be two controls for one state**, which
+  is why the probe reads the body's allocation as `-1` while the compact one is up.
+- **A widget's allocation is not readable in the tick it is first shown.** The compact arm control is
+  created hidden and shown for the first time inside a signal handler, so `gtk_widget_get_width()` in
+  that same tick reads `0` while `gtk_widget_is_visible()` already says `1` — and its sibling's stale
+  allocation (270 px, from when the *body* was still on screen) reads as a live one, because
+  `gtk_widget_get_visible()` is the widget's *own* flag and stays true under a hidden parent. The width
+  only becomes the proof that a control is on the surface **one frame later**, which is why the probe
+  has a `compact_arm_step()` of its own; and the control to compare against must be measured with
+  `is_visible()` or not at all.
 - **Signals start disabled** — enabling is what starts acquisition. A trigger on a
   signal nobody acquires can never fire, so selecting/arming enables it.
 - **The trigger's event window is separate from the display window**, and