[Sad Catapella B6][Numeric correctness] Micrometre conversion overflow can classify radically different pixel sizes as equal #93

Scope and classification

Sad Catapella Batch 6; pinned d7a538e56d41ac1093ba79adcad397c21b3dfd32. Confirmed source-level floating-point defect for finite, positive metadata values that overflow during unit conversion; no test executed.

Evidence

• _number(), lines 699–706 accepts any finite positive float from metadata, including 1e308.
• PhysicalSizes.micrometers(), lines 190–201 returns value * factor without checking that the result is finite. to_micrometers(), lines 271–280 has the same gap.
• metadata._check_pixel_sizes(), lines 795–805 obtains converted sizes with no validity filter before using _same_length(), lines 385–386.

Analytic counterexample

One image has a metadata X/Y pixel size 1e308 meter (finite, positive), another has 0.5 micrometer. The first conversion multiplies by 1e6 and produces +inf. Under the current comparison abs(0.5 - inf) <= 1e-3 * max(0.5, inf), both sides become inf, so the comparison incorrectly evaluates True. Thus _check_pixel_sizes can suppress different_pixel_sizes even with obviously incomparable sizes. The public same_pixel_size(PhysicalSizes(...)) instead raises on nonfinite converted values, leading to inconsistent behavior between API and preflight.

Fix / tests

Always validate finiteness after unit conversion. Define whether conversion overflow makes a size unknown with an explicit warning, or is a named invalid calibration, but never emit inf as a physical length. Fix both PhysicalSizes.micrometers and to_micrometers; ensure metadata._micrometers and pixel_size_groups cannot pass inf/NaN into comparator. Regression cases: 1e308 meter, near overflow boundaries, picometers at tiny scales, known unit cross-conversion, invalid/infinite metadata and valid physically reasonable values. No Numba; simple scalar validation.