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