fix(reader): width-agnostic numeric compare in zone-map pruning (#159)

[dfa1]

Fixes #159.

ScanIterator's zone-map comparator caught ClassCastException and returned 0 — which canPruneChunk treats as cannot prune. Stats decode integers as Long and floats as Float/Double, so a filter value boxed at a different width (Integer on an I64 column, Float on F32) threw internally and silently disabled pruning — a valid, selective predicate degraded to a full scan with no signal.

Fix — key the comparison off the column type, not the boxed operand

• floating column → Double.compare
• unsigned int column → Long.compareUnsigned (U64 stats/values store raw bits, so a value >= 2^63 is a negative Long; signed compare would keep/drop the wrong chunks — a correctness bug, not just perf). U8/U16/U32 zero-extend to a positive Long, unaffected.
• signed int column → Long.compare

Keying off the column also avoids ever routing an integer column through double-compare, which would lose precision past 2^53 and mis-prune (review point #1).

Eq/Neq had their own inline comparator with the same swallow; they now route through the shared one.

⚠️ Behaviour change (review point #2)

A filter value genuinely incomparable to its column (e.g. a String against a numeric column) now raises VortexException during the scan instead of silently disabling pruning. Callers relying on the old silent full scan will see an exception. Called out in CHANGELOG.md.

API

Adds DType.isUnsigned() (exhaustive switch over the sealed set) to classify the column.

Tests

• ZoneMapPruningTest (27): BoxedWidth (Integer == Long, all six operators), Unsigned (U64 >= 2^63 keep/prune correctness), FloatWidths (F32 stat vs Double/Float filters), IntegerColumnFloatFilter (Double filter on I64 compares in the integer domain past 2^53), TypeMismatch (String throws). All groups parameterized.
• DTypeIsUnsignedTest.

Full reader + writer suites green (incl. checkstyle/javadoc).

🤖 Generated with Claude Code