[Sad Catapella B3][Scientific correctness] OME-Zarr pyramid mean corrupts uint64/int64 precision #75

Baseline: d7a538e56d41ac1093ba79adcad397c21b3dfd32. Classification: confirmed arithmetic precision loss by source inspection; no test/benchmark executed.

Evidence: downsample() lines 268–280 first converts every pixel to float64, then averages and casts back. IEEE float64 cannot exactly represent every integer beyond 2^53. OmeZarrWriter.write() and _write_blocks() use this function for all pyramid levels; the histogram/source level 0 is unaffected. Tests only use small uint8 values, and block/whole parity uses uint16/int32/float32.

Analytic counterexample: 2×2 uint64 array with all entries 2**53+1: their exact mean is 2**53+1. The float64 conversion rounds every entry to 2**53, and the overview pixel therefore differs by 1. Values close to uint64 maximum also risk inaccurate clipping/casting, because that limit itself is not exactly representable as float64. This is a scientific copy/overview error, not a claim that raw level-0 pixels or histograms are wrong.

Fix: implement an integer-safe 2×2 rounded mean for 64-bit integer types without float64 loss or sum overflow, with explicit tie/rounding policy matching existing np.rint (ties-to-even). Test 0, signed extreme, uint64 maximum, values >2^53, odd image dimensions and both whole-plane and blocked export. Preserve cross-format agreement. Consider a Numba fused kernel only after exact arithmetic is defined; benchmark against NumPy on uint8/16/32/64 and float images, reporting cold JIT and warmed throughput.