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.