optimize lookup to compete with abseil flat_hash_map

[joshuaisaact]

Why

The elastic hash table was roughly tied with Google's abseil flat_hash_map. This PR optimizes the SIMD lookup path, makes the lookup paper-faithful (100% find rate via multi-tier search), and adds rigorous benchmarking with verification.

What

Implementation changes to src/hybrid.zig:

• Interleave keys and values into a single entries array
• Multiply-only hash with upper-bit bucket indexing
• Software prefetch for entries at probe 0
• Paper-faithful multi-tier lookup via opaque function pointer overflow (100% find rate)
• Early termination on empty slots in the overflow function
• Reduce MAX_PROBES 8 -> 7

Benchmark harness (bench-abseil.cpp, src/autobench.zig, bench-v2.sh):

• Random keys via splitmix64 (identical seeds in C++ and Zig)
• Fair capacity: both sides reserve(n) / init(n)
• Median of 10 runs with 2 warmup discards
• Miss lookup test

Verification (verify-results.md, bench-verify.cpp, bench-realistic.cpp):

• Shuffled vs ordered lookup access patterns
• Abseil internal capacity analysis
• Hash function cost comparison
• Realistic workloads (mixed r/w, hot-key, build-then-read)

Verified results (shuffled random access, n=1M u64 keys):

Load	Hit Lookup	Miss Lookup	Delete
25%	1.21x faster	0.49	2.7x faster
50%	1.18x faster	0.44	2.8x faster
75%	1.08x faster	0.40	2.4x faster
99%	0.86 (abseil 14% faster)	0.39	2.7x faster

Sweet spot: 500K-2M elements at 10-75% load. The tiered metadata layout keeps hot fingerprints (1MB) in L2 while abseil's control bytes (2MB) spill to L3. See verify-results.md for the full verification including caveats.

40+ experiments, ~75% revert rate. Full logs in results-v2.tsv and results-v3.tsv.

References

• Optimal Bounds for Open Addressing Without Reordering (Farach-Colton, Krapivin, Kuszmaul 2025)
• abseil SwissTable