fix: a recompute that renumbered its ring, and readouts frozen under a zoom

Three defects, all of them a window describing data that is not there.

A math edit refilled the derived ring with `clear()`, which renumbers it
from 0, leaving `produced()` short by the inputs' retained base. Since
`live_window_locked()` clamps against every channel's `produced()`, that
one lagging channel answered `n = 0` for the live view, every pause view
and every trigger capture until a whole ring of fresh data had gone by --
the reported freeze, invisible until the ring first wraps, hence its
intermittence. It now restarts with `clear_to(base)`, and
`ChannelBuffer::republish_from(base)` puts the published window back:
`acquire()` is incremental, so a rewrite in place published nothing and
the pyramid went on describing the samples the edit replaced.

The trigger's channel is an index, re-resolved by name after a renumbering
-- but only in `rebuild_enabled_locked()`, so a math add or delete went
through `set_math_channels()` with no restore, the index was clamped to
-1, and `process()` returned at once while the panel still named the
channel. The restore moves into `rebuild_channels()`, which *is* the
renumbering, so no caller can forget it.

And `update_measures()` suppressed its "the window moved" test while an
event was held -- the one mode where a gesture is the only thing that can
move it. Zooming a latched event left the pane describing the whole
captured event. A pinned window needs no exemption: it lands on the range
it already measured and fails the 2 % test by itself.

The checks that missed all three: `UDPSCOPE_PROBE_MATHWRAP_MS` edits a
graph whose ring has already wrapped, which `math_probe` structurally
cannot reach; `[measure-trace]` now prints the mode, the window on screen
and the window the numbers describe; and the dump's `marks_in_window`
counts against the window on screen instead of against the one the marks
were computed over, where it was a tautology.

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

src/ui_app.hpp

@@ -487,6 +487,13 @@ struct App {
   plot::Range measure_window{};
   bool measure_window_valid = false;
   bool measure_was_held = false;
+  /// The window **on screen**, in the same stream seconds, as of the last *tick* -- which is the
+  /// only thing `measure_window` is comparable with. Captured here rather than read back in the
+  /// dump for the reason every other dump field is (see verification.md): the dump runs from the
+  /// destroy handler, after the exit probe has switched the trigger on, and `stream_at_x0()` by
+  /// then answers for a mode no frame was ever drawn in -- which read as a 45000 % drift on a run
+  /// whose every frame was exact.
+  plot::Range measure_view_window{};
   /// What the two walks over one channel's visible window produced, shared by every measurement
   /// on that signal: the window's statistics, and one accumulator per *distinct level* any of
   /// them asked for. Several measurements on one signal must cost two walks, not two each -- and
@@ -1699,6 +1706,9 @@ gboolean trig_trace_probe(gpointer user);
 gboolean eventzoom_wait(gpointer user);
 gboolean eventzoom_probe(gpointer user);
 gboolean math_probe(gpointer user);
+gboolean mathwrap_probe(gpointer user);
+gboolean mathwrap_probe_wait(gpointer user);
+gboolean mathwrap_probe_report(gpointer user);
 gboolean measure_probe(gpointer user);
 gboolean measure_trace(gpointer user);
 gboolean stats_probe_report(gpointer user);