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 ;)