Separate probe construction from recording-specific wiring across format readers

[h-mayorquin]

I think we should try to distinguish between two concepts that probeinterface currently handles through the same code paths:

• "Catalogue probes": pure geometry from the probeinterface library, built via get_probe() or build_neuropixels_probe(part_number). No dependency on any recording.
• "Probes in recording setup": a catalogue probe plus recording-specific state like electrode selection, channel-to-file mapping, and session metadata, fetched from a source file.

Right now most format readers have this logic mixed and entangled together, making it hard to tell whether a bug is in the geometry or in the wiring.

In PR #383 I already separated these concerns for read_spikeglx: it calls build_neuropixels_probe(part_number) to get the full catalogue probe, slices it to the IMRO-selected electrodes, and then sets device_channel_indices as an explicit final step. I think we should try applying the same pattern everywhere. Catalogue-building functions (build_neuropixels_probe, get_probe, and new internal helpers like _build_openephys_probe) would return probes without device_channel_indices set, and format readers would add wiring as a separate step. No new classes or data model changes would be needed.

I think we could start with read_openephys, which is the most pressing case. It still calls the legacy _make_npx_probe_from_description helper (constructs geometry and sets identity wiring in one shot) and has a channel-ordering bug where contacts are sorted by channel ID but wiring stays as identity. The fix would be to extract probe construction into an internal helper that builds and slices the catalogue probe without setting wiring, then let format-aware callers (read_openephys, and eventually read_openephys_binary) set device_channel_indices from the actual data file layout. After that, read_spikegadgets could benefit from the same split since it currently mixes electrode filtering with hardware channel mapping in a single pass. The MEA readers (read_maxwell, read_3brain, read_mearec) are simpler cases since they read fixed-geometry arrays without a catalogue and already set wiring correctly, but they could still be reviewed for consistency.

At the moment, I don't think it is worth introducing new classes or properties into the data model for this distinction. Programmatically separating catalogue construction from recording-specific wiring in the format readers already gets us most of the benefits. That said, I think this distinction should have a prominent place in the documentation so that contributors and users understand the two-phase pattern when working with probes and format readers.