[Sad Catapella N1][Correctness] Block histogram accepts dtype-mismatched pixel arrays and can silently change pixel cardinality #26

Scope / classification

Normalization Batch 1 f784c95e3049483f87466150ffc5764375fa631d. Confirmed unchecked API precondition with a deterministic counterexample, tests not executed.

Evidence

• compute_block_histogram API takes a declared dtype but does not validate that each yielded array actually has that dtype.
• _small_integer_histogram, lines 447–457 increments total by the source element count but views raw data in chunks of the declared dtype's itemsize. For a uint8 two-element block with declared uint16, values.view('u2') collapses two input pixels to a single 16-bit value; returned histogram sum becomes 1 while total_pixel_count is 2.
• For wide types, _wide_histogram measures extrema in incoming array dtype while _ordered_keys silently casts to declared dtype for the rank search, potentially disagreeing with bin assignment and actual values.
• Existing block tests test_histogram.py:224–235 always pass plane.dtype with homogeneous blocks.

Impact

Programmatic callers can produce internally inconsistent histogram counts or false range statistics without an explicit mismatch error. This threatens reproducibility of independent streamed block readers.

Fix / acceptance

Validate dtype identity on every nonempty block before interpreting pixels. Permit nonnative byte-order variants when they represent the same scalar type and are converted correctly (separate issue #); reject kind/itemsize mismatches with a named ValueError mentioning declared and observed dtypes and block position. Do not silently cast across signedness, integer/float or width. Add tests for mixed dtypes across blocks, uint8 blocks declared uint16, float64 declared float32, signed/unsigned and correctly equivalent byte orders; assert counts always sum to valid pixels. Validate block generators without forcing full-plane materialization.