feat: the x axis is relative to now, and an export carries both clocks

Three asked-for changes, one commit because they are one coordinate system.

The live axis is a fixed [-window, 0] with the newest sample at 0, so x reads
as an age and the labels stand still while the trace rolls under them. That
makes the display clock distinct from the stream clock for the first time, so
`ScopeModel::stream_at_x0()` becomes the single conversion between them
(`display_x = stream_t - stream_at_x0()` in all four modes) and a snapshot
carries its own origin in `EventSnapshot::x_offset`. The pause view is now
rebased like an event's, reversing an earlier deliberate choice: a frozen
absolute-stamped picture would sit a whole uptime right of a newest-relative
axis. That also fixed a latent bug, the export adding `trigger_time()` to a
*paused* view's stamps.

The status bar says how long you have been paused -- wall time, since the
producer never stops, through `format_elapsed()` so the field cannot widen.

The export writes two time columns: `time`, the axis as displayed, and
`abs_seconds`, the stream's own clock for the same sample. f64 seconds and
not the wire's integer, because `udps_frame_t::values` is a `const double*`
and the integer never exists in this process.

Cursors and measurement marks move in opposite directions under the rolling
axis, deliberately: a cursor is a position on screen and stays put, a mark
names a sample and travels with it. `App::measure_window` is stream-clocked
for a sharper reason -- a display-coordinate live window never moves, so the
"the window moved" recompute would never fire again.

Moves the deps/plotter pin to 58473db, which stops a time label's mantissa
reaching its own radix: a one-second tick differenced off a live axis read
`1e+3ms`.

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

src/help/12-export.txt

@@ -17,15 +17,17 @@ the format follows the path's extension.
 • The stored rate is not always the wire rate. A window long enough to need decimation is stored
   averaged at a lower rate, and the export carries <i>that</i> — read the status bar's ⓘ popover
   for the figure before trusting a sample count.
-• Two time columns. <tt>time</tt> is the display timeline (relative to the trigger edge while an
-  event is held) and <tt>stream_time</tt> is the source's own clock. Both are strictly increasing
-  and evenly spaced; duplicate or backwards stamps would mean the file held two clocks.
+• Two time columns. <tt>time</tt> is the display timeline — negative ages ending at 0 while
+  streaming, offsets from the trigger edge while an event is held — so it is the x you read a
+  value at on screen. <tt>abs_seconds</tt> is the source's own clock for the same sample, which
+  is what lets two exports taken in different modes line up. Both are strictly increasing and
+  evenly spaced; duplicate or backwards stamps would mean the file held two clocks.
 • An export taken <i>mid-capture</i> writes the partly filled window that is on screen, which is
   shorter than the event span. Export outside a capture if you want the whole event.
 
 <b>Example</b>
 
 A 2 s window at 10 kS/s over 3 traces writes 20001 rows and 5 columns
-(<tt>time</tt>, <tt>stream_time</tt>, three signals). The <tt>.npy</tt> is
+(<tt>time</tt>, <tt>abs_seconds</tt>, three signals). The <tt>.npy</tt> is
 <tt>64·⌈(10+len(header)+1)/64⌉ + rows·(16 + 4·cols)</tt> bytes. Read it back with
 <tt>pd.DataFrame(np.load(path))</tt>.