fix: a file view states its pin once, so the axis holds still

`set_data_pin()` takes a range and `pin_event_window()` a pre/post
split; the file view handed the split to both. On a recording whose
stamps start before zero that stored a pin that no longer held the
data, so every second frame found the pin wrong and stated it in full
again -- rewriting the group's x range and discarding the user's
gesture with it. The view alternated between the file's span and the
corrupted one at the frame rate: a flicker in which no pan, zoom or
click survived. `[drop-probe]` now reports the view and the count of
pin statements, which must stay at two for a whole run.

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

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

@@ -90,6 +90,17 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   window, which is a re-open with a new extent and is a new event, stated in full. `[boxzoom-probe]`'s
   `zoomed=` is the guard, and it is a reading to take in **both** modes: live and file must both read
   `1`.
+- **`set_data_pin()` takes a *range*; `pin_event_window()` and `pinned_window_is()` take the pre/post
+  *split*.** The three are used in one breath by the file view's statement and by the held event's, and
+  the two forms are not interchangeable: for data over `[lo, hi]` it is `set_data_pin(lo, hi)` against
+  `pin_event_window(-lo, hi)`. Handing the split to `set_data_pin()` stores the pin as `[lo, -lo]`-ish,
+  so the next frame's `pinned_window_is()` reads false, the pin is stated in full again, and the view
+  alternates between the file's span and the corrupted pin at the frame rate -- the flicker in which no
+  interaction survives, because every second frame rewrites the group's range. It is invisible on a file
+  whose stamps are all positive (the corrupted pin is then *wider* than the data and
+  `hold_pinned_window()` never clamps) and on one that ends at 0 (the pin inverts, and the clamp returns
+  early), which is why it reached a user on a recording spanning `[-4..16]` and nothing before it.
+  `[drop-probe]`'s `repins=` is the reading: **2 for a whole run**, not one per frame.
 - **A pinned view is navigable *within its data*, and that is the bound -- not the request.**
   Two things had to agree for this, and both were wrong in the same direction:
   the **pause** pinned on the window it asked for rather than on the snapshot it got (a cut

docs/claude/probe-readings.md

@@ -997,7 +997,7 @@ configuration that carries settings, is the defect this exists for — a saved h
 ## `[drop-probe]`
 
 ```
-[drop-probe] signals=4 channels=4 rows=4 slots0=[sine|||]
+[drop-probe] signals=4 channels=4 rows=4 slots0=[sine|||] view=[-3.999690..15.999670] repins=2
 [drop-probe] dropped signal 0 -> 1 slots=[sine|sine||]
 [drop-probe] dropped signal 1 -> 1 slots=[sine|sine|square|]
 ```
@@ -1007,6 +1007,8 @@ configuration that carries settings, is the defect this exists for — a saved h
 | `rows` | the column count, capped at `RowSet::kMaxRows` — one row per trace | rows sized four signals to one row: the only row fills and *every* drop is refused ("plot 1 already holds four signals"), which reads as a scope that cannot plot anything |
 | `dropped … -> 1` | 1, and the row gains that trace | a drop that cannot find a free slot, or a signal with no channel to bind |
 | `channels` | one per signal | a file whose columns did not become channels, so nothing can be plotted at all |
+| `view` | the file's own span, or whatever the user last zoomed to — never a *sub-range of it the user did not ask for* | a pin that no longer holds the data: `view=[3.999690..15.999670]` against a file spanning `[-4..16]` is the pin written as a pre/post split where a range belongs |
+| `repins` | **2**, for the whole run, however long | the file view stating its pin per frame instead of refreshing its numbers. Each statement writes the group's range, so the axis alternates between the file's span and the pin's and no gesture survives: `repins=116` at three seconds is one per frame, and it reads on screen as a flicker in which nothing can be clicked |
 
 ## `[events]`
 

docs/claude/verification.md

@@ -377,12 +377,25 @@ as distinct from the fault injection below, which exercises ingest:
   the plan, this file arrived as its **last 0.9 s** and nothing in the log said so.
 - **A loaded file can be plotted.** `UDPSCOPE_PROBE_DROP_MS` drives the drop handler the way a drag
   from the signal panel does, on a file opened with `--open`: it must read
-  `[drop-probe] signals=4 channels=4 rows=4 slots0=[sine|||]` — **`rows` equal to the column count**,
+  `[drop-probe] signals=4 channels=4 rows=4 slots0=[sine|||] view=[-3.999690..15.999670] repins=2` —
+  **`rows` equal to the column count**,
   one trace per row — and each drop must return `1` and add its trace (`dropped signal 1 -> 1
   slots=[sine|sine|square|]`). `rows=1 slots0=[sine|square|ramp|noise]` with every drop returning `0`
   is the defect this exists for: rows sized four signals to one row fill the only row, so the app
   reads as one that cannot plot anything. A file-mode run must also write **no session** for the
   default `127.0.0.1:8000` (`App::source_port` is 0), or it overwrites that source's saved layout.
+- **A file view states its pin once.** `repins` on the line above must read **2** whenever the probe
+  is scheduled — at one second or at seven — and `view` must be the file's whole span. A file's extent
+  does not change while it is open, so the tick refreshes the pin's *numbers* and writes the group's
+  range only when the view first becomes an event. Reading it against the decimated file above
+  (`/tmp/long.npy`, stamps `[-4..16]`) is the case that matters: with the pin written as a pre/post
+  split where a range belonged it read `view=[3.999690..15.999670] repins=116` at three seconds —
+  the axis alternating between the file's span and a corrupted pin every frame, which on screen is a
+  flicker in which no pan, zoom or click survives to the next frame. A file whose stamps are all
+  positive, or which ends at 0 (an export's own window), hides it: the corrupted pin is then wider
+  than the data, or empty, and the clamp never fires. `UDPSCOPE_PROBE_PAN_MS` on the same run is the
+  other half — `allowed=1` and a `view` that is still the zoomed range when the drop probe reads it
+  later is interaction actually taking.
 - **The chooser's Waveforms page**: `UDPSCOPE_PROBE_WAVEFORMS=1` prints
   `[sources] waveforms: N recent <path>(ok|missing) … page=waveforms`, and `UDPSCOPE_PROBE_WAVE=<path>` sets
   the field the file dialog's callback sets and prints `[sources] picked waveform <path>` — then the