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