ui: each pane carries its own switch, the same one the header bar has

The trigger pane and the cursors pane now have a `GtkSwitch` in their heading, and it is *one control in
two places* with the header bar's button: both run the same action (`run_app_action()`), and
`sync_panel_switches()` re-reads each pair from the toolbar's state after any change, so clicking either
end moves both. A pane whose feature is off is disabled, which is exactly the state you need the switch
in, so it belongs *in* the pane rather than only in the toolbar.

Three things it needed:

- **The sensitive target moved to the pane's body.** A control inside an insensitive parent cannot be
  clicked, so a switch that greyed out with its own pane could never turn it back on. `on_trigger_toggled`
  and `on_cursors_toggled` now disable `trigger_body` / `cursors_body`, and so does the startup default;
  the headings, with their switches, stay live.
- **The trigger's heading moved out of `trigger-panel.ui`** and is built in `build_trigger_panel()`,
  which returns the heading row and the panel together. It has to be a sibling of the body for the switch
  to stay usable, and keeping it in the file would have meant the file owning a widget the code must
  arrange. The file's own panel is unchanged otherwise, so the `[trigger panel:]` counts still read.
- **A guard on the sync.** Setting a `GtkSwitch` emits `notify::active` for a programmatic write just as
  it does for a click, so without `App::panel_switch_sync` the program's own write would come back as a
  click and flip the feature again.

Readings, both directions in one line:

    trigger panel sensitive before the probe toggled it: 0; … ; pane switches live while their panes are off=1
    panel switches: trigger=1/1 cursors=1/1 drove_toolbar=1  (pane switch / header bar button)

`pane switches live …=1` is the design's point and is read before anything turns either pane on; `0` would
be a switch drawn, greyed and useless. The trigger pair is moved from the *toolbar* end and the cursors
pair from the *pane* end, so the line carries both halves of the sync, and `drove_toolbar=1` is the pane's
own switch having turned the cursors on with the button following. `trigger panel sensitive …=0` is the
body, not the panel.

Verified: the two lines above; `[side-tab-probe] … advanced=4`; `make test-ui` 14 files; zero
`Gtk-CRITICAL` and no missing icon. Docs: the new reading in `probe-readings.md` with what a `0` means,
the invariants bullet for the one-control-in-two-places rule and its two traps, the sidebar bullet's
sensitive target, and the README note on why the switch is in the pane.

src/ui_app.hpp

@@ -227,6 +227,18 @@ struct App {
   /// is what it costs.
   int dbg_switcher_w = -1;
   int dbg_switcher_h = -1;
+  /// The panes' own switches and the header bar's buttons, read together by the exit probe: the two
+  /// must agree, and `dbg_panel_drove_toolbar` is the pane's switch having moved the button.
+  int dbg_panel_switch_trigger = -1;
+  int dbg_toolbar_switch_trigger = -1;
+  int dbg_panel_switch_cursors = -1;
+  int dbg_toolbar_switch_cursors = -1;
+  int dbg_panel_drove_toolbar = -1;
+  /// Both panes' switches being *sensitive* while their panes are off -- read before anything turns
+  /// one on. It is the whole point of putting them in the heading: a control inside an insensitive
+  /// parent cannot be clicked, so a switch that went insensitive with its own pane could never turn
+  /// it back on.
+  int dbg_panel_switch_live = -1;
   int dbg_switcher_policy = -1;
   /// Whether `name_side_tabs()` has named the pills: it can only run once the switcher is mapped.
   bool side_tabs_named = false;
@@ -236,6 +248,16 @@ struct App {
   GtkWidget* cursors_reset = nullptr;
   /// The cursors panel's root, kept because cursors-off disables it rather than hiding it.
   GtkWidget* cursors_panel = nullptr;
+  /// The panes' *own* switches, in their header rows, and the panel bodies those switches disable.
+  /// The switch and the header bar's button are one control with two places to click: each runs the
+  /// same action, and `sync_panel_switches()` re-reads both from the toolbar's state after any
+  /// change, so they cannot disagree.
+  GtkWidget* trigger_switch = nullptr;
+  GtkWidget* cursors_switch = nullptr;
+  GtkWidget* trigger_body = nullptr;
+  /// True while `sync_panel_switches()` is writing the switches: setting a `GtkSwitch` emits its own
+  /// `notify::active`, and without this the program's own write would come back as a click.
+  bool panel_switch_sync = false;
   /// The cursors pane: listing what the instruments read -- T0/T1/dT always, per row an Y1/Y2/dY
   /// where rulers are up, and in `mix` mode the value each cursor crosses each trace at.
   GtkWidget* cursors_mode_drop = nullptr;
@@ -1388,6 +1410,10 @@ void on_right_click(GtkGestureClick* gesture, int, double x, double y, gpointer
 gboolean on_drop_channel(GtkDropTarget*, const GValue* value, double x, double y, gpointer user);
 void on_side_tab_changed(GObject*, GParamSpec*, gpointer user);
 void select_side_tab(App& app, const char* name);
+/// Reads each pane's own switch back off the header bar's button, and the other way round: the two are
+/// one control in two places, and `panel_switch_sync` keeps the write from looking like a click.
+void sync_panel_switches(App& app);
+void on_panel_switch_toggled(GObject* obj, GParamSpec*, gpointer user);
 void update_side_visibility(App& app);
 void on_sidebar_toggled(GtkToggleButton* button, gpointer user);
 void rebuild_signal_panels(App& app);