Fix Neuropixels handling in SpikeGadgetsRawIO

[h-mayorquin]

SpikeGadgetsRawIO crashes with ZeroDivisionError when opening any Neuropixels .rec file from Trodes 2.8.2 onwards (closes issue #1844 and maybe #1810). Trodes writes chanPerChip="0" on those headers to signal that the recording has no Intan chip layout, and the existing reader divides by that value without a guard. While investigating, I found a separate silent bug in the existing NP1 data on gin: it writes chanPerChip="32" despite using a Neuropixels probe, so the old divisibility check passed and the file went through _produce_ephys_channel_ids, producing fabricated chip-style channel ids that did not match any real hardware channel.

The fix switches the discriminator from chanPerChip to the SpikeConfiguration.device attribute, which Trodes writes as "intan", "neuropixels1", or "neuropixels2" (absent on legacy files, which were always Intan). The hwChan path is now the default for every recording, and the Intan chip-id synthesis runs only as an override when device confirms the recording is Intan and the chip math works out. That route fixes both the NP2 crash and the silent NP1 misrouting in one change.

[dkassybayeva]

If in old version channel ids were incorrect, does it mean the whole pre-processing, including kilosort, needs to be rerun for those sessions to get correct ids and probe positions?
I.e. does it affect channelmap.prb construction?

[alejoe91]

If in old version channel ids were incorrect, does it mean the whole pre-processing, including kilosort, needs to be rerun for those sessions to get correct ids and probe positions? I.e. does it affect channelmap.prb construction?

I don't think it will, but @h-mayorquin can confirm!