fix: a readout mark sits on the sample it quotes, not on the pointer's column

The value was already the nearest stored sample's, but every mark drawn for it was
placed at the *marker's* x with that sample's y -- so the dot the eye follows and the
number in the pane were a different datum whenever the marker fell between two samples.
Half a sample period is nothing across a whole window and the width of the panel once a
few samples span the axes, which is the only zoom at which anyone is asking which point
a number came from.

`place_crossings()` now goes through the plotter's new `Plot::crosshair_point()`, which
returns the quoted sample's x alongside its y -- one lookup for the mark and the number,
so they cannot name different samples. The dot consequently sits a little off its own
vertical cursor line: the line is where the marker is, the dot is the datum being quoted,
and between two samples those are two places.

Pin moves to the upstream commit that does the same for the library's own hover crosshair
and draws its mark larger than a trace's sample dots, and that keeps the old blend
reachable as `CrosshairValue::Interpolated` -- which udpscope never states.

Verified: plotter suite 370 cases 0 failed; `[cursors-probe]` lines=3 marks=6 with
`first mark at x=3.292400 y=-0.525175` against the pane's `-525.17 mV`; `[help]`
pages=14 parsed=14 closed ok.

CLAUDE.md

@@ -756,12 +756,27 @@ far the largest file.
   average* over `time_stride` samples, so a number between two stored samples is a second
   estimate laid over the first that nothing on screen or in an export holds; and past the sample
   spacing the polyline is a line the renderer drew, so a point on it reports the drawing. The
-  change is in `deps/plotter` and unconditional — no setting, because the library had no business
-  offering a readout the data does not contain. `CrosshairRow::marker` is placed from the same y,
-  so the dot lands on the quoted sample and **sits beside the polyline at a deep zoom, by
-  design**: one y feeding both is what keeps the mark and the number from disagreeing. The guards
-  are the library's `crosshair_value_is_the_nearest_sample` and `[cursors-probe]`'s `first mark at
-  x=.. y=..` agreeing with the pane's first value.
+  change is in `deps/plotter`, which keeps the blend as `CrosshairValue::Interpolated` for a host
+  whose x is a quantity it is willing to interpolate — the nearest sample is the **default** and
+  **udpscope never states the other**, so a `set_crosshair_value_mode()` call appearing here is a
+  regression, not a feature.
+  **Both the mark and the number come from one call, `Plot::crosshair_point()`**, which returns
+  the quoted sample's own **x** as well as its y — so every mark this app draws for a readout is
+  *snapped to the sample it quotes*. The library's `CrosshairRow::marker` and the cursors pane's
+  `mix` crossing annotations (`place_crossings()`, which must use `crosshair_point()` and not
+  `crosshair_value()`) are both placed from it. Two consequences that look like defects and are
+  not: the mark **sits beside the polyline at a deep zoom** (one y feeding both the number and the
+  dot is what keeps them from disagreeing), and a crossing dot **sits a little off its own
+  vertical cursor line** — up to half a sample period, invisible at a whole-window view and the
+  width of the panel at a few samples across, which is the only zoom at which anyone is asking
+  which point it is. The line says where the *marker* is; the dot says which *datum* is quoted.
+  The hover mark is also deliberately *larger* than a trace's own sample dots
+  (`Style::crosshair_marker_px` 9 against `marker_px` 3), because a snapped mark lands among them
+  and at their size reads as one more sample. The guards are the library's
+  `crosshair_value_is_the_nearest_sample`, `the_crosshair_marker_snaps_to_the_sample_it_reports`,
+  `crosshair_interpolated_mode_blends_the_two_samples` and
+  `the_crosshair_mark_is_bigger_than_a_sample_dot`, plus `[cursors-probe]`'s `first mark at x=..
+  y=..` agreeing with the pane's first value.
 - **The cursors are read back from the plots only while a gesture is on that row.** `Cursor::x`
   is the *free* pointer position while a drag runs and the snapped value otherwise -- which is
   what the app itself wrote a frame earlier, or the snap of it. A tick that reads a row on