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`.

src/ui_app.hpp

@@ -281,9 +281,18 @@ struct App {
   static constexpr int kTriggerSummaryRows = 8;
   GtkWidget* trigger_summary_keys[kTriggerSummaryRows] = {};
   GtkWidget* trigger_summary_values[kTriggerSummaryRows] = {};
+  /// The compact line's arm control. It lives in the pane's *heading*, the part that stays on screen when
+  /// the body is hidden, and `sync_arm_buttons()` states it: present only while trigger mode is on and the
+  /// pane is locked, which is the one combination where the body's own Arm button has gone with the body.
+  GtkWidget* trigger_summary_arm = nullptr;
   GtkWidget* trigger_edit = nullptr;
   GtkWidget* signals_edit = nullptr;
   int dbg_trigger_locked = -1;
+  int dbg_summary_arm_off = -1;       ///< the compact line's arm control with the trigger *off*
+  int dbg_summary_arm_visible = -1;   ///< the compact line's arm control, locked and with the trigger on
+  int dbg_summary_arm_sensitive = -1;
+  std::string dbg_summary_arm_label;  ///< its text, which is the armed state in the user's words
+  int dbg_summary_arm_width = -1;     ///< its allocation a frame later: 0 means "not laid out"
   int dbg_signals_locked = -1;
   int dbg_trigger_body_visible = -1;
   /// The compact line the locked trigger pane shows. It is the pane's whole content in that mode, so it
@@ -1476,6 +1485,14 @@ void row_drag_sidebar(App& app, bool dragging);
 /// bodies, their [edit] buttons and the signal list's rows all follow from `trigger_locked` and
 /// `signals_locked`.
 void sync_trigger_summary(App& app);
+
+/// Both arm buttons -- the panel's and the compact line's -- from the one armed state the producer keeps in
+/// `model->trigger_armed()`. The label was written from four places (the click, the toolbar toggle, the
+/// curator's re-read, the start-up default) and a second button would have needed a fifth copy of the same
+/// two lines; the drift that costs is a button reading "Arm" while the engine is armed. Sensitivity, and
+/// the compact button's visibility, are stated here too and read from the toolbar toggle -- the control
+/// that owns `enabled`, per the restore rules -- so no caller needs the model lock to state any of it.
+void sync_arm_buttons(App& app);
 void apply_pane_lock(App& app);
 void on_pane_edit_clicked(GtkButton* button, gpointer user);
 void apply_trigger_layout(App& app, const LayoutState::Trigger& t);