fix: a clock glitch is bridged and a channel is known by name, so a capture keeps its t0

Two defects behind one report ("a trigger during a capture overrides the first,
and the hold-off does not apply"); the second is also what made a spike in one
channel look like the acquisition resetting.

The trigger engine keyed its invalidation on the trigger channel's *index*, which
every rebuild of the channel list renumbers -- enabling a signal that sorts before
it is enough. Any rebuild therefore abandoned an open capture and set no hold-off,
so the next edge inside the post window became t0. It keys on the channel's name
now, which changes only when the source genuinely does.

A packet whose stamps jump more than 256 packet spans ahead is now rejected as a
fault and *bridged* at the declared cadence, instead of poisoning the monotonic
mark (which pinned every later packet flat at the glitched value) and condemning
the next good packet. Only four consecutive failures abandon the declared time
signal, and that fallback no longer wipes the rings: the arrival clock is anchored
to continue from the monotonic mark, so the history is still on one timeline --
the wipe is what made one glitching packet look like the stream restarting from 0.
The declared unit is resolved before those checks, since they weigh the stamps
against a cadence in seconds.

Guards: UDPSCOPE_PROBE_TRIGRENUM_MS prints t0_held=1 through the real widgets,
and the mock's --time-glitch-at/--time-glitch-by injects the clock fault.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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

@@ -30,6 +30,21 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   out empty: any stream whose time signal advances in large steps drove it to its
   1 S/s floor, the count came out as 1, and the engine latched on the edge sample
   itself. **Do not reintroduce a rate estimate on this path.**
+- **The engine identifies its channel by *name*, never by index.** `TriggerEngine::configure()`
+  drops an open capture when the trigger moves to a different channel, and it is re-called from
+  `Acquisition::on_data()` on **every packet** out of `model_.trigger()`. `TriggerConfig::channel`
+  is an index into `channels()`, and that index is not stable: every rebuild of the channel list
+  renumbers it — enabling a signal that sorts before the trigger's own is enough — and
+  `ScopeModel::set_signal_enabled()` re-resolves the trigger by name and writes the *new* index
+  back. Keying the reset on the index therefore made any such rebuild abandon the capture **and
+  set no hold-off**, so the next edge inside the post window became t0: that is the "the trigger
+  re-triggers during a capture and the hold-off does not apply" defect, and it needed no glitch
+  and no user action beyond enabling a channel. The name changes when the source genuinely
+  changes, so a deliberate re-point still resets. The rebuild also replaces the `BufferStore`, so
+  the surviving capture's pre side is short and the snapshot reports its own `pre_s` — which may
+  be **negative** when the new ring starts after the edge. That is a faithful reading, not a
+  defect: `[-pre_s, post_s]` still describes the samples the snapshot holds. The guard is
+  `UDPSCOPE_PROBE_TRIGRENUM_MS`, whose `t0_held=1` is the assertion.
 - **A pinned window is *clamped* into the event every frame, and a zoom in is allowed.**
   While an event is held, a capture is filling, or the view is paused, `tick()` calls
   `RowSet::hold_pinned_window()`, which caps the span at `[-pinned_pre_, +pinned_post_]`'s and