feat: locked panes for a returning user, and the trigger is persisted

Two panes, two modes. **Locked** is what a returning user gets: the trigger pane shows one line saying
what it is set to, the signal list shows only the signals that are on, and neither offers a control that
changes the configuration — each heading has an `[edit]` button (the Adwaita `emblem-system-symbolic`,
swapping to `emblem-ok-symbolic` in configuration mode) that flips its pane. A **first run** — no session
file for that source — never reaches `apply_layout()` and comes up in configuration mode, because
configuring the host is what a first run is for. The mode is a mode and not a setting, so it is
deliberately not persisted.

The locked signal list drops the rows of every signal that is off, which is the whole of "show active
signals": the list already filters on nothing, so the lock is one `continue`. With the rows go the acquire
tick, the overflow menu (Information, Calibrate…, Delete, rename) and the `MATH` divider's `+` — and the
colour chip stops being clickable, because choosing a colour is configuration too. Dragging a signal onto
a plot stays: that is which view shows what, not what the scope is set up to do.

**The trigger is persisted, settings and state both** — the settings *even while it is off*, which is the
point: a trigger configured once and switched off is still the trigger you come back to. `LayoutState`
gains fifteen flat `trigger_*` keys; the channel is stored by *name* (every rebuild renumbers the
channels, the model's own rule) and the two enumerations as **the words the panel's dropdowns show**,
because an index ties the file to a declaration order — the lesson `math_op_at()` already carries. The
words are shared with the panel now (`trigger_type_text()` and friends build the dropdown arrays), so the
two cannot drift.

Two ordering traps, both found by running it:

- **The channel name resolves twice over.** `rebuild_trigger_signals()` picks up
  `App::pending_trigger_channel` when the stream arrives *after* the load, and `apply_trigger_layout()`
  resolves it itself when the channels are already there — without the second path the name stayed
  pending past the one rebuild that would have used it, and the trigger silently sat on channel 0
  (`summary='pulse width · sine …'` where the session said `square`).
- **The trigger's state is applied by pressing the control, not by setting a flag**: the toggle is set
  *outside* the `updating_panels` window `apply_layout()` uses, because a toggle set inside it emits
  `toggled` into a handler that returns at once and nothing would happen — no arming, no events button,
  no sensitivity.

Verified, in both modes and both directions:

    panes: trigger=locked signals=locked body_visible=0 summary='window · square · 0.3…0.6 · 20 % pre'
    panes: trigger=config signals=config body_visible=1 summary=''
    signals panel: labels=2 list=1 rows=7 signals=2 math=4 divider=1

The locked trigger pane is 42 px tall against 580 unlocked. A hand-written session round-trips: every
value it named came back in the panel's own controls, `trigger=1/1` (the state arrived and the pane's
switch followed it), and the file the app wrote back carried all fifteen keys with the untouched ones at
their defaults. `[side-tab-probe] … advanced=4` on its documented recipe; `make test-ui` 14 files; zero
`Gtk-CRITICAL` and no missing icon.

Docs: the `panes:` reading with what each field means, the corrected `labels=` note (the panel's frame is
counted above the list now, because the heading sits in a heading row), the invariants for both the
persistence and the lock, the README's deviation note, and the removal of its claim that the trigger has
never been persisted — it is now, and the locked view is built from exactly that.

README.md

@@ -1111,8 +1111,11 @@ assertion, being a stream stamp rebased by whichever rebuild last dropped histor
 `probe-readings.md`.
 
 A shape's own rows are the only ones shown; the rest are hidden, so the panel never offers a
-width to a window trigger. The condition is **not** persisted in the session file — the session
-has never persisted the trigger — so a restart comes up on an edge trigger.
+width to a window trigger. The condition **is** persisted in the session file, together with trigger
+mode itself: the settings are written even while the trigger is off, because a trigger set up once and
+switched off is still the trigger you come back to. The signal it names is stored by *name* — every
+rebuild renumbers the channels — and the shapes by the words the panel's dropdowns show, so a
+reordered enumeration cannot reinterpret a file.
 
 ### Searching the buffer
 
@@ -2397,7 +2400,11 @@ now — they are listed so they are not mistaken for anything else:
   cursors and the ruler for Measure, a sine crossing its trigger level and the channel list
   for Signals (the same picture the toolbar's trigger button carries), drawn as a
   32x16 pair so both motifs are legible at a glance — with the words kept as each pill's tooltip and
-  accessible name. Each pane's heading also carries its **own switch**, the same control as the
+  accessible name. Both panes also have a **locked** mode, which is what a returning user gets: the
+  trigger pane shows one line saying what it is set to, the signal list shows only the signals that are
+  on, and neither offers a control that changes the configuration — each heading has an `[edit]` button
+  to switch to the full pane, and back. A **first run** (no session file for that source) comes up
+  unlocked, because configuring the host is what a first run is for. Each pane's heading also carries its **own switch**, the same control as the
   header bar's button — clicking either moves both — because a pane that is *disabled* while its
   feature is off is a pane whose controls you would otherwise have to leave to turn it back on. The
   design spec had the switcher showing *titles* and neither page an