Reconsider how chunk sizes should be computed

[ieivanov]

INFO:iohub.convert:Found Dataset D:\2026_02_08_mantis_v2_rebuild\argolight_2d_dots_oblique_1 with dimensions (P, T, C, Z, Y, X): (1, 1, 1, 1187, 256, 1600)
WARNING:iohub.convert:Chunk size 1187 on axis 2 adjusted to 1 (dimension 1187).

Chunking of size 1 along z is inefficient. What is the core requirement of aligned chunks for the Dask library, as implemented in _adjust_chunks_for_divisibility? Couldn't this dataset be split into three chunks of size, say, [(512, 256, 1600), (512, 256, 1600), (163, 256, 1600)]

This dataset is available for testing at: /hpc/instruments/cm.mantis/2026_02_08_mantis_v2_rebuild\argolight_bullseye_cal_1

[srivarra]

"What is the core requirement of aligned chunks for the Dask library, as implemented in _adjust_chunks_for_divisibility?"

Dask doesn't require chunks to evely divide the dimension. Dask can natively handle a final chunk which is smaller than the rest.

The even-divisibility constraint was set to prevent data loss in #367, but yeah, this is overly aggressive. We can probably replace the method of "find the exact divisor" with "find the nearest reasonable chunk size".

[ieivanov]

We can probably replace the method of "find the exact divisor" with "find the nearest reasonable chunk size".

That sounds like the right solution