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/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