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.

docs/claude/probe-readings.md

@@ -164,7 +164,7 @@ Two lines of the self-check output are assertions in disguise:
 - `[cursors-probe] <action> mode=.. on=D pane_sensitive=D t0=.. t1=.. dt=.. T=[..] lines=N [..]`
   (stderr, `UDPSCOPE_PROBE_CURSORS_MS`) — walks `vertical` → `horizontal` → `both` →
   `mix`, then moves a marker *through the plot* (`Plot::set_cursor_x(..., Free)`, which is
-  what a drag does) and reports again. `pane_sensitive` is the cursors *panel's* sensitivity, not a
+  what a drag does) and reports again. `pane_sensitive` is the cursors *panel body's* sensitivity, not a
   revealer's child: with the cursors off the panel stays exactly where it is and its cells blank to `--`,
   because a readout whose instruments are off has no sample to quote. **The times must survive every mode change**: they
   are the `RowSet`'s one pair, and a mode that parks the markers must not read them back
@@ -1139,6 +1139,29 @@ library measures and draws the rect in tests of its own.
   defect this reading exists for, and it was invisible from the frame alone: the file view pinning its
   axis from the ring each frame is what swallowed the gesture.
 
+## `panel switches:` and the trigger panel's default sensitivity
+
+```
+[udpscope]   trigger panel sensitive before the probe toggled it: 0; signal list items=1 selected=0; column visible after sidebar toggle off=1; pane switches live while their panes are off=1
+[udpscope]   panel switches: trigger=1/1 cursors=1/1 drove_toolbar=1 (pane switch / header bar button; `drove_toolbar` is the pane's own switch having moved the button)
+```
+
+Each pane's heading carries its own switch, and it is the *same* control as the header bar's button:
+both run the same action and both are re-read from the toolbar's state afterwards, so they cannot
+disagree. The two lines are the claim, in both directions:
+
+- **`pane switches live while their panes are off=1`** — read before anything turns either on, because
+  it is the whole point of putting the switches in the headings: 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.
+  **`0` is that defect**: the switch is drawn, greyed, and useless.
+- **`trigger=` and `cursors=` are `pane switch / header bar button`**, and the pairs must agree. The
+  trigger's is moved from the *toolbar* end (these steps toggle that button to arm the trigger) and the
+  cursors' from the *pane* end, so one line carries both directions of the sync. **`drove_toolbar=1`**
+  is the second direction's assertion: the pane's own switch turned the cursors on and the header bar's
+  button followed.
+- `trigger panel sensitive …=0` is the *panel body*, not the panel: the heading row, with its switch,
+  stays live. `1` here while trigger mode is off is the pane not being disabled at all.
+
 ## `[sidebar-probe]`
 
 ```