`read_spikegadgets_neuropixels` applies a display offset to multi-probe geometry; should it?

Today read_spikegadgets_neuropixels shifts each probe in a multi-probe .rec by multi_probe_plot_offset_um * (probe_index - 1) on the x axis (250 um for NP1.0 and NP2.0 single-shank, 1000 um for NP2.0 4-shank). The shift was introduced in #260 to keep multi-probe ProbeGroup plots visually distinguishable: the catalogue probe sits at origin, so without it two or three NP1.0 probes would stack on top of each other. In #418 I kept the line, and in #441 I generalised the magnitude per format, but the display-only transform is still baked into contact_positions.

As far as I am aware read_spikegadgets_neuropixels is the only multi-probe Neuropixels reader that does this. Downstream consumers that read absolute coordinates (stereotactic registration, custom multi-probe layouts) see invented values for probes 2 and 3, with no annotation and no opt-out. I think the better fix lives in the plot function: detect overlap and spread probes only when rendering. That keeps contact_positions honest and would help any multi-probe reader, not just SpikeGadgets. What do you think?

Start at read_spikegadgets_neuropixels and trace how multi-probe contact_positions are populated, then review the display offset introduced in #260 and generalized in #441. Check the plotting path to determine where overlap spreading belongs. Done means absolute contact_positions remain unmodified, while multi-probe plots can still separate overlapping probes during rendering.