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.

README.md

@@ -1153,10 +1153,25 @@ second, undeclared estimate laid over the first, and nothing on screen or in an
 holds it. And at a zoom past the sample spacing it is visibly not the datum the pointer
 is over: the polyline between two samples is a straight line the renderer drew, and
 quoting a point on it reports the drawing rather than the data. A tie reads the earlier
-sample. The fix is upstream and unconditional (`deps/plotter`, `crosshair_span()`'s `t`
-is now a selector rather than a blend factor), so the library's own hover crosshair
-changed with the pane — which is the point, since both are the same lookup and a user
-comparing them must not see two numbers.
+sample. The fix is upstream (`deps/plotter`, `crosshair_span()`'s `t` is a selector rather
+than a blend factor), so the library's own hover crosshair changed with the pane — which is
+the point, since both are the same lookup and a user comparing them must not see two
+numbers. Upstream keeps the blend as `CrosshairValue::Interpolated` for hosts whose x is a
+quantity they are willing to interpolate; the nearest sample is the default and udpscope
+never states the other.
+
+**The crossing dot is on the sample, not on the marker's column.** The dot is placed
+through `Plot::crosshair_point()` — the same lookup as the value, returning the quoted
+sample's own x as well as its y — so the mark the eye follows and the number in the pane
+are the same datum. The two x's differ by up to half a sample period: nothing at a
+whole-window view, and the whole width of the panel once a few samples span the axes, which
+is exactly the state in which a reader is asking "which point is that?". It therefore leaves
+the dot a little off its own vertical line by design — the line says where the *marker* is
+and the dot says which *datum* is being quoted, and when the marker is between two samples
+those are two places. The library's hover crosshair snaps the same way and draws its mark
+`Style::crosshair_marker_px` across (9 logical px against a trace's own 3 px sample dots),
+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.
 
 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