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>

docs/claude/invariants-measurements.md

@@ -20,6 +20,17 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   own -- `top`/`bottom`/`amplitude` take a second read of that same **bucket** list and never of
   the window (the flat-level invariant below). **Adding a type must not add a pass** -- that is
   what `compute_measure()`'s `stats` argument is for.
+  **The "it moved" test is asked in every mode, a held event included.** Suppressing it while
+  held (`moved = ... && !held`) is the shape the pinned-window fix first took, and it is wrong
+  for the one mode where a *gesture* is the only thing that can move the window: a latched event
+  zoomed forty times over left the pane describing the whole 2 s event with `passes` frozen,
+  which is the reported "measurements move when zooming or panning on data" -- the numbers stand
+  still while the data under them moves. Nothing is needed for the pinned case anyway, because a
+  window that is merely re-pinned satisfies `swin == measure_window` exactly and fails the move
+  test on its own; a pause is the standing proof, since `display_mode()` reports `Paused` rather
+  than `Held` for one and the statistics probe already requires `n` to advance by at most one
+  across a two-second pause. The held/live state is still a recompute of its own, so a mode
+  change is not missed.
   The marks' *ink* is set where they are created (`install()` in `plot_host.cpp`): 0.75 px and
   dashed 4/4 through `Plot::set_cursor_stroke()`, which is per cursor because the trigger marker
   (also a cursor) keeps the solid `line_width_px` stroke. A new measure mark must take that