fix: going live restores immediately instead of after a few trigger toggles

The symptom was "view a recorded event, click `<live>`, then toggle the trigger a few times before it
starts streaming again". The mechanism was the restore's own gate: `restore_live_state()` waits for the
*stream's* channel list, because the trigger's stored channel is a **name** and a file view that renamed its
channels (`square (A)`) must be gone before the name means the right signal — and that wait was gated on
`generation()` having moved since *Go live* was pressed.

That gate could never be satisfied in the common case. A **single** event keeps the stream's own channel
names, and the restarted client's CONFIG is identical — which the model treats as *no change on purpose*
(`same_stream_signals()`: "the honest recovery is nothing") — so nothing bumped the generation and the
restore sat there. Toggling the trigger *is* a structural change and moved it, which is exactly the
workaround the report describes.

The gate is now the question it was actually asking: is the snapshot's channel name resolvable against the
live channels (or did the snapshot name none)? For a single event that is true as soon as the client has a
channel list at all, so going live is immediate; for a group the names are renamed, so it waits for the
stream's own CONFIG exactly as before — which is what the gate was for. `live_restore_generation` is still
captured and printed (`gen=a/b`) as information, not as the gate.

Verified against the documented reading, both ways into a file view, from a session with a window and a
trigger so the paired fields have something to disagree with:

    [events] live restored (after replay):  window=0.500000 (want 0.500000) trigger=1 (want 1) channel='square' (want 'square') level=0 (want 0) enabled=1 armed=1 pinned=0 held=0 mode=2 pending=0 gen=6/3
    [events] live restored (after a group): window=0.500000 (want 0.500000) trigger=1 (want 1) channel='square' (want 'square') level=0 (want 0) enabled=1 armed=1 pinned=0 held=0 mode=2 pending=0 gen=16/12

Every want satisfied, `pending=0` in both, `make test-ui` 14 files, zero `Gtk-CRITICAL`. Docs: the
invariants' bullet rewritten around what the restore waits for and why the generation was the wrong
question, and `probe-readings.md` gaining the thing that cost me two runs to find — those four paired
fields are the probe's capture of the live view, so a bare first run reads the application's defaults and
is not a defect; reproduce the documented line from a session that has a window and a trigger.

docs/claude/invariants-trigger-and-pinning.md

@@ -224,13 +224,18 @@ is the complaint this answers.
   - `rebuild_trigger_signals()`, finding a `channel` of `-1` after the rebuild renumbered the
     channels, silently settles on the first signal *and* re-defaults the level -- which is why
     `trigger_level_touched` is restored with the configuration.
-- **It waits for the stream's own channel list, gated on `generation()` having moved.** The restored
-  name has to be resolved against the live channels, and those do not exist until the first CONFIG of
-  the restarted client lands on the producer thread. `App::live_restore_generation` is the generation
-  read when *Go live* was pressed; `live_restore_pending` stays set until it differs **and**
-  `channels()` is non-empty. A `pending=1` that never clears is therefore a reading about the
-  *stream*, not about the restore -- see `invariants-session-and-export.md` for the save that made it
-  stick at `channels=0`.
+- **It waits for the trigger's channel *name* to resolve again, not for `generation()` to move.** The
+  restored name has to be resolved against the live channels, and a file view that renamed its channels
+  (`square (A)`) must be gone first or the name selects the wrong signal. `App::live_restore_pending`
+  stays set until `channels()` is non-empty **and** a channel carries the snapshot's name (or the
+  snapshot named none). Gating that on the generation was wrong in the common case: a *single* event
+  keeps the stream's own channel names, and the restarted client's CONFIG is identical, which the model
+  treats as **no change on purpose** (`same_stream_signals()`) -- so the generation never moved and the
+  restore waited for something that could not happen. What shook it loose was toggling the trigger,
+  which *is* a structural change: "click live, then toggle the trigger a couple of times" was the
+  symptom. A `pending=1` that never clears is a reading about the *stream* (no channels yet), not about
+  the restore -- see `invariants-session-and-export.md` for the save that made it stick at
+  `channels=0`.
 - **Only the two controls a file view actually moved are restated** -- the signal dropdown and the
   level spin. The rest of the trigger panel was never touched, and writing to a control fires its
   handler, so the ones with nothing to put back are left alone. Both writes are inside