[Audit/Correctness] XY-ordered mask headers pass preflight but fail read_mask #68

Evidence (Sad Catapella, Batch 1; main d7a538e)

• _known_axes accepts both YX and XY because it checks membership and uniqueness, not plane order.
• _header_issues then accepts an XY mask if the image's physical Y/X sizes match by role; mask_size_issues similarly compares sizes by the declared roles.
• read_mask preserves the pixel plane's axis order, then unconditionally requires axes == 'YX'. Thus an accepted XY mask cannot be read.
• Current tests cover 1-pixel YX and TYX but not XY.

Impact

A preflight and histogram run can accept and record masks that the public reader and optional mask relationship scan later refuse. This violates the input contract's intent that accepted named axes are usable; it gives late failures rather than a clear preflight diagnosis.

Fix / acceptance

Choose and document one policy explicitly: (a) if masks are never reordered, reject XY (and any non-YX retained order) in mask header validation with a named error, or (b) transpose the selected pixel plane to YX in a documented, audited reader. Do not silently reorder. Add XY and XY-with-T/Z fixtures testing preflight, run and read agreement and non-square shapes.

Classification: confirmed source-level contract inconsistency; actual fixture execution still needed.