Migrate read_spikegadgets to the catalogue pattern

[h-mayorquin]

This migrates read_spikegadgets to use build_neuropixels_probe + get_slice, the same pattern that read_spikeglx (#232), read_openephys (#406, #409), and read_imro (#410) already follow. Instead of constructing probe geometry from scratch by parsing XML coordinates, the reader now builds the full 960-contact catalogue probe and slices it to the active electrodes using the channelsOn bitmask. Device channel indices are mapped from the SpikeNTrode hwChan attributes. This was the last Neuropixels reader that bypassed the catalogue (#405).

The SpikeGadgets XML format does not include the probe part number, so I hardcode "NP1000" for the catalogue lookup. I verified that all 10 staggered NP 1.0 variants in the catalogue (NP1000, NP1001, NP1010-NP1014, PRB_1_2_0480_2, PRB_1_4_0480_1, PRB_1_4_0480_1_C) share identical 2D geometry: contact positions, pitch, stagger, shank width, tip length, shank length, contour, electrode count, and ADC/MUX tables. The only fields that differ are metadata (description, datasheet, is_commercial) and shank_thickness_um (Z-axis), none of which probeinterface uses. Because we cannot attribute a specific part number, model_name and description are cleared after slicing. This assumption would be wrong for NP1015-NP1017 (NHP linear) and NP1300 (Optopix), but the SpikeGadgets headstage is documented as supporting standard rodent Neuropixels 1.0 probes, which are the staggered variants.

The newer Bennu datalogger (https://spikegadgets.com/products/bennu-neuropixels-datalogger/) advertises NP 2.0 support. When .rec files from that device become available, we will need test data and likely a way to detect the probe type from the XML to extend this reader.

[alejoe91]

I think I can get some NP2 test data ;)

[h-mayorquin]

@alejoe91 I added the example you shared recently to the repo.

The reader now branches on SpikeConfiguration.device and hardcodes NP2014 for the NP2 path (same geometry-equivalence argument as NP1000: all 4-shank NP2 catalogue variants share 2D geometry). I also dropped the channelsOn bitmask and derive active electrodes from SpikeNTrode elements for both NP1 and NP2, because on your NP2 file channelsOn is packed differently (692 bytes) and individual_channel_toggling is all -1. The SpikeNTrode-derived set matches the bitmask exactly on NP1, so this is a refactor, not a behavior change.

Your example only activates one shank, so we are still missing a true 4-shank example, but I guess that can be done later.

[h-mayorquin]

I can also separate the PRs with the migration first and then 2.0 support if you want @alejoe91

[h-mayorquin]

@alejoe91

• To keep this simpler, I have restricted this PR to SpikeGadgets Neuropixels 1.0 and will do 2.0 support in a follow-up.
• I have ensured that all the preprocessing-relevant information is available on the probe coming out of read_spikegadgets: AP and LF gains (from the APGainMode / LFPGainMode fields in the .rec XML), adc_range_vpp (from the catalogue), and the ADC multiplexing per-contact annotations (adc_group and adc_sample_order, via _annotate_probe_with_adc_sampling_info). The probe now carries the same metadata that read_spikeglx and read_openephys_neuropixels provide.
• I think we should also disambiguate read_spikegadgets the way we did for Open Ephys in Rename read_openephys to read_openephys_neuropixels and add has_neuropixels_probes #427, since SpikeGadgets headstages can record non-Neuropixels probes too. See Rename read_spikegadgets to read_spikegadgets_neuropixels and add a Neuropixels detector #436

This should be ready.2