ui: the trigger panel's frame is a .ui file

The panel's shape -- the heading, one labelled row per setting, the two buttons that
run it, and the search block -- now lives in src/ui/trigger-panel.ui. Every control
that carries a value stays in code and is appended into the file's row: a dropdown's
model and a spin's range are the application's, a label is text a translator owns, so
that is where the line runs. `row_for()` is `labeled_box()`'s arrangement with the
labels moved into the file; the thirteen old calls to `labeled_box()` here are gone and
its eleven uses elsewhere are untouched.

`sync_trigger_rows()` now guards the rows it shows and hides, because a row that comes
from the file can be missing rather than merely misnamed.

The frame is read back by a new dump line:

  trigger panel: boxes=13 controls_inside=13/13 search_widgets=4/4 search_inside=4/4

where `controls_inside` is what a drifted id breaks -- a control built and never placed
leaves the panel with a field missing and nothing else complaining -- and
`[defaults] trigger: 0.001 0.002 0 0.001 0 50 0.01` still reads the seven spins in the
same tree order, which is the check that the restructure kept the panel's contents.

Two days of grief came out of one GTK fact, now in the invariants: an expander's child
is not in the widget-parent chain (`gtk_widget_get_parent()` is NULL for it even after
the window is presented, while `gtk_expander_get_child()` returns it), so the probe
walk had to start there instead of at the panel. The throwaway program that settled it
is what stopped the workaround -- a second root in the file plus a code attach -- from
being the answer.

docs/claude/invariants-gtk-and-chrome.md

@@ -298,3 +298,14 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   than no mnemonic, because the underscore is there in the source for a reader to trust. `Conn_ect` freed
   it. Rows on different pages of a preferences dialog may share a letter: an unshown page cannot be
   activated.
+
+- **A `GtkExpander`'s child is not in the widget-parent chain.** `gtk_widget_get_parent()` on the widget an
+  expander holds answers NULL, before *and* after the window is presented, while `gtk_expander_get_child()`
+  returns it -- measured all three ways (the `.ui`'s `child` property, a code `gtk_expander_set_child()`, a
+  code-made expander). So a probe that walks parents to prove a widget is inside a panel reads 0 for
+  everything behind an expander, on a panel that is entirely correct; the walk has to start at
+  `gtk_expander_get_child()`. That mistake cost a false regression, a "the property does not attach it"
+  conclusion drawn from it, and a pointless second root in the file before the throwaway program settled it.
+  Related: `gtk_expander_set_child()` asserts that its child has no parent yet, so a block the `.ui` has
+  already put in the panel cannot then be handed to an expander -- the file's `child` property is the right
+  way, and it works.

docs/claude/probe-readings.md

@@ -1161,3 +1161,21 @@ mnemonic. It is FALSE on `AdwPreferencesRow` by default, which is why these titl
 literal underscore; anything below the full count is that bug back. Read by property name rather than
 through one row type, for the reason in `invariants-gtk-and-chrome.md`. The form's line appears only when
 `UDPSCOPE_PROBE_NEWHOST` drives the form.
+
+## `trigger panel:`
+
+```
+[udpscope]   trigger panel: boxes=13 controls_inside=13/13 search_widgets=4/4 search_inside=4/4
+```
+
+The trigger panel's frame, read from the window: `boxes` is the row boxes the `.ui` holds, `controls_inside`
+counts the thirteen controls the code built and then appended into those rows, `search_widgets` is the four
+search buttons having resolved by id, and `search_inside` is those four being inside the block the expander
+opens onto. A control built and never placed -- an id that drifted between the file and the code -- reads as
+`controls_inside` below 13 while every other line still looks right, which is the panel that has a field
+missing.
+
+The search walk starts at `gtk_expander_get_child()`, not at the panel: an expander's child is not in the
+widget-parent chain at all, so walking up from a search button reaches no ancestor of the panel (see
+`invariants-gtk-and-chrome.md`). `[defaults] trigger:` prints the same panel's seven spins in tree order, so
+the two lines together read what the file gave and what the code put in it.