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/invariants-gtk-and-chrome.md

@@ -166,8 +166,9 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   heights, so one shared scroller would leave a switch scrolled where the new page never asked to
   be). The reason is the one this trap teaches: five sections competing for one 320 px column left
   every one of them short of room. A *feature's* on/off is no longer a visibility at all -- the
-  trigger's and the cursors' toggles set their panel's **sensitivity**, so the panel stays where it
-  is and the settings you are about to switch back on do not vanish while you look for them. The
+  trigger's and the cursors' toggles set their pane's **body** insensitive, so the pane stays where it
+  is and the settings you are about to switch back on do not vanish while you look for them. The *body*
+  and not the pane, because each pane's heading carries its own switch (see the next bullet). The
   trap itself does not go away with the widget: a stack's hidden page measures 0x0 too and is still
   given the leftover width, so **ask about state, not about size** carries over unchanged. Every
   allocation read in the sidebar is a debug capture, and each reads 0 on the page that is *not*
@@ -183,6 +184,16 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   **tooltip and accessible name** from the page's name, then hides the empty label that would otherwise
   leave the icon off-centre. An icon-only pill is still a named control for a screen reader, and
   `switcher: … pills=2 labels=0 names=2` is the reading for all three facts at once.
+- **A pane's heading switch and the header bar's button are one control in two places.** Each pane's
+  heading (`build_trigger_panel()` builds the trigger's, `cursors-panel.ui` has the cursors' in its
+  `head`) carries a `GtkSwitch` that runs the *same action* the toolbar button runs, and
+  `sync_panel_switches()` re-reads each pair from the toolbar's state after any change — so clicking
+  either end moves both, and `panel switches: trigger=1/1 cursors=1/1` is the reading. Two traps:
+  a `GtkSwitch` emits `notify::active` for a *programmatic* write as well, so the sync holds a guard
+  (`App::panel_switch_sync`) or the program's own write comes back as a click; and the switcher must
+  stay *out* of what the pane disables, because a control inside an insensitive parent cannot be
+  clicked — a switch that greyed out with its own pane could never turn it back on. That is why the
+  sensitive target is the pane's **body** (`trigger_body`, `cursors_body`) and not the pane.
 - **A list box outlives the children of the pane it sits in, and the teardown order is not yours to
   choose.** Tearing the window down finalizes the events pane's buttons, then the list box, and the
   list's own `selected-rows-changed` then reaches a handler holding the freed pointers: four