[Sad Catapella B5][Scientific integrity] Aggregate OME-Zarr fingerprint misses changed chunks when newest mtime is unchanged #86

Baseline / classification

Adversarial audit Batch 5 at d7a538e56d41ac1093ba79adcad397c21b3dfd32. Confirmed algorithmic collision, reproducible by controlled file-size and mtime operations; repository tests were not executed.

Implementation evidence

• source_fingerprint() represents a Zarr directory using only sum of file sizes and maximum mtime_ns, not per-file paths, versions, digests, or individual mtimes.
• FileEntry.same_source() relies on these two values for incremental reuse. run_experiment() keeps histograms without reading pixels when they match; check_sources() makes the same decision for downstream bricks.
• Existing Zarr test modifies a chunk by raising that chunk's mtime above the prior maximum; it does not test a modified chunk whose mtime remains below an unrelated newer file.

Deterministic counterexample (test proposal)

Create a Zarr store with at least two chunk files of fixed-size uncompressed content. Give chunk A an mtime of 1000ns and chunk B an mtime of 2000ns; record the folder fingerprint. Replace chunk A's pixels in place with different bytes of the same length, and set its mtime to 1500ns (or restore its original time). The newest file is still B. Aggregate file size and max mtime are identical, so source_fingerprint is unchanged, check_sources returns no change, and an incremental run reuses histograms of pixels that no longer exist. Equivalent aggregate collisions are possible with same-length edits and preserved timestamps for TIFF, but Zarr's maximum over files creates this gap even when a changed file's mtime advances normally.

Impact

Silent reuse of scientifically stale histograms and downstream normalization statistics for modified image data.

Fix / acceptance

Make provenance policy explicit. Prefer a deterministic inventory of relative chunk/metadata paths plus each file's size/mtime (not just sum/max); for robust scientific integrity, use per-file hashes or a storage-provider immutable version/ETag where available, with a selectable strict mode. Do not claim cheap timestamps are cryptographic proof. Add multi-chunk collision test, same-size overwrite, metadata mutation and unchanged-store fast path. Benchmark cold/warm 1k–1M chunk trees and hashing overhead; Numba is inappropriate for filesystem I/O. Coordinate with #77 on scalable metadata indexing.