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