fix(intanrawio): one-file-per-signal digital streams are packed in one word per sample

[SAY-5]

Fixes #1853. For one-file-per-signal Intan recordings the digital input/output .dat file holds one packed 16-bit word per timestamp regardless of how many digital channels are enabled, but the memmap layer divided the file size by the channel count and reported half the true sample length, which then crashed _demultiplex_digital_data with a broadcast shape mismatch when more than one digital channel was active. The fix treats the digital streams as single-column files and adds a small unit test covering the demultiplex shape contract.

[h-mayorquin]

Hi, do you have test data that you can share with us so we can stub it and add is a regression?

[SAY-5]

I don't have hardware data to share; I worked from the Intan one-file-per-signal docs and existing memmap test shapes, so the unit test in this PR asserts the demultiplex shape contract rather than driving a real recording. Happy to coordinate if any maintainer can share a small two-or-more-DIN one-file-per-signal capture and we can fold it into the existing intan test fixtures.

[SAY-5]

I don't have the original capture from #1853, but the existing one-file-per-signal fixture (test_files/intan/one-file-per-signal) only ships a single digital channel so it can't catch the broadcast-shape regression. Happy to expand the fixture or have the issue reporter share a multi-channel digital file if that's preferred.

[h-mayorquin]

Ok, thanks. This is good but we are pending on testing data.

I asked Charlie in the issue if he might be able to share some with us if the data is stubbed. Otherwise, I might have one in a week or two. This can wait a bit unless some user wants to jump in and provide example data to expedite this. If not, we will merge for sure before the release.