fix: a zoomed trace is drawn on the x its readout quotes

gather() staged x as f32 relative to the series' own x0() -- the start of
the whole retained window -- so the quantisation was a fraction of the
ring rather than of the view: 1.9 us at 20 s of retained data, which at a
10 us view across a 716 px axis is over 100 px between where a sample is
drawn and the x a readout quotes for it (crosshair_point() reads x_at()
in exact f64). It halved on every zoom out, which is what made it read as
"zooming in makes the crosshair select a point beside the data".

The origin is now the caller's (plotter c2c8c59): the renderer passes the
visible range's minimum, so the error is a fixed 2^-24 of what is on
screen -- about 4e-5 px over a 700 px axis -- at any zoom. The parameter
sits before out_xy so every call site is a compile error rather than a
silent change of behaviour.

The renderer no longer reads series.x0() at paint time at all, which
removes two of the three symptoms of the torn window_x0_ read by
construction; the ink probe's now-vacuous kept_fixed_x0 walk goes with
them, replaced by a drawn-vs-quoted pixel figure. neighbours() still
tests the visible range against x_at(0), so the cache stays load-bearing.

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

README.md

@@ -1194,6 +1194,31 @@ those are two places. The library's hover crosshair snaps the same way and draws
 since a snapped mark lands among those dots and at their size would read as one more sample
 instead of as the answer to the question the hover asks.
 
+**A zoomed-in trace is drawn on the x its readout quotes, which needed the gather's origin to
+become the caller's.** Separately from the half-sample offset above — which is a property of
+*which datum* is quoted — there was an offset in *where the polyline was drawn*, and it grew
+with the zoom. `plot::data::Series::gather()` stages x as `f32`, which cannot hold an absolute
+epoch time, so it emits a value relative to an origin the consumer adds back in `f64`. That
+origin was fixed at `x0()`, the start of the **retained window**: the f32 then had to resolve
+2^-24 of the whole ring however little of it was on screen — 1.9 µs over 20 s of retained data
+— while a readout reads `x_at()`, exact `f64`. At a view 10 µs wide across a 716 px axis
+(14 ns a pixel) that is over a hundred pixels between the drawn sample and the x reported for
+it, and it halves with every zoom *out*, which is why it read as "zooming in makes the
+crosshair pick the wrong point".
+
+The origin is now an argument, and `Renderer::draw_traces` passes the **visible range's
+minimum** — so the quantisation is 2^-24 of the span on screen, a fixed 4e-5 of a pixel, at
+every zoom. The fix is upstream (`deps/plotter`), where the parameter was deliberately placed
+*before* the output buffer so that every one of the library's and this app's call sites was a
+compile error rather than a silent change of behaviour. One simplification fell out of it:
+`stage_xy()` took a gather origin and a draw origin, those are now always the same value, and
+the linear case hands the gathered buffer straight to the line batch with no per-point copy.
+Two guards: the library's
+`a_gather_origin_at_the_view_keeps_a_deep_zoom_on_the_sample_it_quotes`, which measures the
+error in pixels both ways (under 0.05 px with the view's minimum, over 10 px with `x0()`), and
+this app's `trace ink:` line, which now reports `worst drawn-vs-quoted P px` over the raw-level
+paints of a whole run.
+
 The readouts are a **table**: a header naming the columns, then one row per instrument —
 `| who | A | B | delta |`. The first row is the two times and their difference, and the
 rows below it are the rulers (one per row, in `horizontal`/`both`) or the traces (in