fix: a still frame's measurements are the frame's, not the viewport's

A measurement is a statistic of the window the pane is *about*, and on a
pinned view -- a held event, a paused stream, an opened file -- that is the
frame, not the part of it on screen. The pane followed the viewport
instead, so a wheel on a latched event moved `average` and `top`: the
reported "when measuring a still frame, moving the zoom makes measurements
such as average or top change". Nothing about the data had changed; the
user was only looking closer.

The window is `RowSet::pinned_range()` while the pin frames the view and
the viewport otherwise, and the choice is made in `update_measures()` --
the call site -- rather than inside `MeasureWindowReader`, because it is
*booked* as well as read: that window is what the "it moved" test compares
against `App::measure_window`, so a gesture inside the pin spends no
recompute either, and a reader that chose its own would leave a pinned
view recomputing every gesture frame for a number that cannot change.
`pinned_range()` is now the one expression of the pin's extent, shared
with the framing (`hold_pinned_window()`, `fit_x()`), and the reader is
handed the window instead of reading the plot. Live is unchanged: there
the window really moves and the statistic follows it, and the
accumulator's rule about what resets the history is about neither.

`UDPSCOPE_PROBE_MEASUREPIN_MS` is the guard, three legs of before/after a
gesture on the row's own axis. On a latched event zoomed to a quarter
(`view=[-1..1]` -> `[-0.25..0.25]`, `pin` unchanged): `same=4/4
for_same=1 pass_delta=0`, every value bit-identical -- `average=0.000000
top=0.957975 peak to peak=2.000000 amplitude=1.915950` both sides. The
same on a pause taken from it. Since the key `for=` follows `pin=` now,
`[measure-trace]` gained the field, so a held run reads `for==pin` with
`swin` free to sit inside it. On a live view a zoom to an eighth reads
`same=0/4 for_same=0 pass_delta=3 span_after=0.125000 follows=1` with the
values moving -- the case the rule must not swallow.

Before the fix the same probe reads `same=1/4 for_same=0 pass_delta=1
span_after=0.500000` on the held event (`top` `0.957975` -> `0.957966`)
and `same=0/4 span_after=0.125000` on the pause (`top` `0.957944` ->
`0.358614`). Live reads the same either way.

Also fixed, found by the pause leg: pausing while an event is *held*
froze an **empty** picture. `on_pause_toggled()` read `stream_at_x0()`
after setting the pause state, and that accessor follows the display --
`paused` with no pause view published yet answers `-display_epoch()`,
which on a held event is 0, so the cut searched the ring at edge-relative
x, found nothing, and the frame bound an empty snapshot: every
measurement `--`, every ruler gone (`ev=650001` on the probe's line now,
`ev=0` before). The offset and the window are read first, which is the
offset the axis is actually displaying. The live case is unaffected, which
is why the pause probe, which pauses a live view, never saw it.

Docs corrected where they asserted the old half-truth: the invariants now
separate the accumulator's rule (unchanged) from the window a value is
computed over (this change), the trigger/pinning file names the pin as
load-bearing for both the framing and the numbers and records the pause
ordering rule, `verification.md`/`probe-readings.md` describe the new
probe and `pin=`, and the README and the manual say what a still frame
measures.

Checked: `cmake --build build --clean-first -j4` 0 errors and the
documented three warnings; `make -C build test-ui` 13 ok; `make -C build
test-help` green; an exit-dump run 0 Gtk-WARNING/Gtk-CRITICAL and `gtk
warnings: 0`; `[measurepin-probe]`, `[pan-probe]` (`held=1`,
`allowed=1`, `limited=1`), `[pause-probe]` (`event_size` non-zero exactly
while paused, `axis` inside `frozen_x`, `skips` 0 live / 30 paused),
`[stats-probe]` (`dn=1` across the pause), `[zoom-probe]` (`gap_px=0.0`
at every step) and `[measure-probe]` + the dump's `measures
window:` (all-types run `marks_in_window=4/4`, `pin=off` live) on the fast
mock. `measure cost:` is unchanged in kind: `raw=37298 (0.0%)` of
`covered=121704537`, 1.04 ms a pass -- the runs that read higher are the
probe's own zoomed-to-a-slice windows, where the window is legitimately
shorter than a bucket.

docs/claude/invariants-measurements.md

@@ -20,17 +20,38 @@ 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 window a value is computed over is the *pin* while the view is pinned, and the viewport
+  otherwise.** A pinned view -- a held event, a paused stream, an opened file -- is a *still
+  frame*: the data behind it does not change, so a pan or a zoom only looks closer. Measuring the
+  pin (`RowSet::pinned_range()`, the same accessor `hold_pinned_window()` clamps into, so "what
+  frames this view" has one expression) is what makes a gesture change **no value at all** --
+  and it is decided in `update_measures()`, at the call site, rather than inside
+  `MeasureWindowReader`, because the decision is also *booked*: the window
+  `MeasureWindowReader` is handed is the same one the "it moved" test compares against
+  `App::measure_window`, so a gesture inside the pin spends no recompute either. A reader that
+  chose its own window would leave a pinned view recomputing on every gesture frame for a number
+  that cannot change (457 passes in one run is the shape that mistake took).
+  This test has been wrong in both directions and the reasoning is worth keeping. Suppressing it
+  while held (`moved = ... && !held`) left the pane describing the whole 2 s event
+  (`for=[0.47..2.47]`) while a 50 ms slice of it was on screen; *removing* the exemption was the
+  opposite mistake, and it is the reported "when measuring a still frame (a triggered event, or a
+  paused stream) moving the zoom makes measurements such as average or top change, which should
+  never happen". The two are one question asked of two different windows: **which window is this
+  pane about** (the pin, while pinned) and **has it moved** (asked of that window in every mode).
+  Answers: a pinned view still recomputes when it should -- a fresh latch, a re-stated pin, a new
+  snapshot, the held/live change -- and a settled one satisfies `swin == measure_window` exactly
+  and so reads `moved == false` on its own.
+  `[measurepin-probe]` is the reading: on a latched event zoomed to a quarter of itself,
+  `same=4/4 for_same=1 pass_delta=0` with the values bit-identical and `for=` still at the pin;
+  the same on a pause taken from a held event. Live is the case that must **not** be swallowed,
+  and it reads `same=0/4 for_same=0` with a positive `pass_delta`, `span_before=2.000000`,
+  `span_after=0.125000` and `follows=1` -- the results window narrowed with the viewport and the
+  values moved with it. The
+  one path that is *not* this rule is the window control: `apply_time_window()` unpins
+  (`set_time_window()` clears `pinned_`), so for the frames before the held branch re-states the
+  pin the view really is live-framed and the pane measures the viewport -- `[measure-trace]`
+  prints `pin=off` for exactly those frames, which is what makes them legible rather than looking
+  like the defect again.
   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
@@ -268,6 +289,10 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   changed".** An explicit Reset, an add/edit/delete (all three funnel through
   `rebuild_measures_pane()`), a CONFIG, and a change of display window each change the
   *question*, so the history is cleared. A pause, a resume, a trigger latch, a pan and a zoom do
-  not: they change which samples answer it, which is precisely what averaging over many windows
-  is for. The pane-wide toggle does not reset either — it only shows and hides labels that are
-  always created and always fed, so reading the plot for a moment does not cost the history.
+  not: on a **live** view they change which samples answer it, which is precisely what averaging
+  over many windows is for -- and on a **pinned** one they change *nothing*, not even a value
+  (the window invariant above), so there is nothing for the history to see either way. The rule
+  is about the *accumulator* only; it is not a claim that a gesture leaves a value alone, which is
+  a property of the window a value is computed over and is the other half of this change. The
+  pane-wide toggle does not reset either — it only shows and hides labels that are always created
+  and always fed, so reading the plot for a moment does not cost the history.