tp: Add O(1) hashmap companion to single-column integer indexes

For single-column indexes on non-null integer/Double columns with no
duplicates, BuildIndex now also builds a uint64->row_index hashmap
alongside the sorted permutation vector. The query planner prefers the
hashmap for Eq constraints via a new IndexedFilterEqHashMap bytecode,
which does one O(1) Find() instead of an O(log n) binary search over
the permutation.

Motivation: resolve_groups in the flamegraph pipeline does a LEFT JOIN
on a unique hash column. Previously each join probe took
O(log n) through IndexedFilterEq; on large heap-graph traces the
merged step was ~21s because of 8.4M log-n probes. On a 1.3M-object
trace where the binary search is still only 17 comparisons, this
measures at ~10% speedup on the merged step (0.179s -> 0.160s). The
win grows with row count.

Phase 1 (sorted-column binary search) now skips Eq specs on columns
that have a hashmap index companion, so those fall through to Phase 2
(IndexConstraints) where the new bytecode is emitted.

Correctness: full diff-test suite (1356 tests) is green and manual
A/B on the flamegraph pipeline produces bit-identical output between
hashmap-on and hashmap-off.

The hashmap companion is opt-in via CanBuildHashMapEqIndex: single
column, non-null, integer-like type, no duplicates (checked by an
exact scan over the sorted permutation, because the
HasDuplicates/NoDuplicates metadata is conservative on 64-bit hash
columns).