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>

src/ui_app.hpp

@@ -644,6 +644,11 @@ struct App {
   /// afterwards is the glitch.
   int dbg_notrace_frames = 0;
   int dbg_notrace_last = -1;
+  /// Times the file view has *stated* its pin rather than only refreshing its numbers. A file's
+  /// extent does not change while it is open, so this must read **1** for a whole run: stating the
+  /// pin writes the group's range, which discards whatever gesture the user had left on the axis,
+  /// so a count that grows with the frames is both the flicker and the reason no interaction took.
+  int dbg_file_repins = 0;
   /// The widest *minimum* width the side column or either pane has ever demanded. The side
   /// column is a fixed 320 px by design, so a figure far above that is a label whose text drove
   /// its own minimum -- the "layout must not depend on content" rule broken, and the only known