perf: expand geohash sets on packed integers instead of strings

[mailletf]

Problem

expand_geohash_set walked the grid through geohash::neighbors, which allocates eight Strings per cell, and kept cells in a HashSet<String> hashed with SipHash. The allocation churn dominated — the actual work is integer arithmetic on a grid.

Separately, the zero-hop case paid a full O(N·8) boundary pre-pass before ever looking at n_hops, just to return its own input.

Fix

Pack each hash into its u64 form and walk with ghbits::neighbors, keeping cells in an FxHashSet<u64> and rendering back to base32 once at the end. Ring expansion no longer needs the boundary pre-pass at all: cells already in the set are never re-added, so interior cells fall out of the frontier on their own after the first pass.

Input hashes are still validated when n_hops == 0 — packing does it — so malformed input is rejected as before.

Benchmarks

End to end from Python, whitehorse p6 (24,571 input cells), output identical in every case:

expansion_m	before	after
0 m	15.1 ms	4.3 ms	3.5×
700 m	16.8 ms	6.0 ms	2.8×
3000 m	19.1 ms	6.4 ms	3.0×
12000 m	31.4 ms	8.6 ms	3.7×

⚠️ Behaviour changes

• Latitude now clamps at the poles instead of wrapping. geohash::neighbors reports eight neighbours for a top-row cell such as zzzzzzzzzzzz, three of which have wrapped over the pole to the opposite edge of the grid — so expanding a polar geography used to jump to the other hemisphere. Covered by test_ghbits_neighbors_clamp_at_poles and test_expand_at_the_pole_does_not_cross_over.
• A set mixing precisions is now an error rather than each cell expanding on its own grid. Every caller in this crate already validated uniform precision before calling in.

[mailletf]

This change is part of the following stack:

• fix: don't drop multipolygon parts whose seed lands in an earlier part #30
  • perf: cover polygons by descending the geohash tree #31
    • perf: expand geohash sets on packed integers instead of strings #32 ◀
      • fix: cap the expansion hop count instead of hanging near the poles #33
        • fix: release the GIL while covering a polygon #34
          • chore: delete the dead handbrake cover #35
            • chore: cargo fmt #36
              • perf: add Arrow-native WKB and EWKB output #37
                • perf: add Arrow-native encode and coordinate decode #38
                  • perf: optionally dictionary-encode geog_id in the Arrow mapping output #39
                  • perf: cover large polygons across Rayon workers #40

_{Change managed by git-spice.}

[Copilot]

Pull request overview

This PR improves the performance of geohash set expansion by switching the expansion walk from String geohashes (via geohash::neighbors) to a packed u64 representation with an integer-based neighbor walk, then rendering back to base32 only at the end. It also removes the prior boundary pre-pass so zero-hop expansions can return quickly after validation.

Changes:

• Added ghbits::pack and ghbits::neighbors to support packed (u64) geohash parsing and neighbor enumeration with pole clamping.
• Reworked expand_geohash_set to expand rings using FxHashSet<u64> and integer neighbor traversal, converting back to HashSet<String> only once at the end.
• Added unit tests covering pack/unpack roundtrips, invalid-character rejection, neighbor behavior (including pole clamping), and expansion correctness vs a reference implementation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mailletf]

Agreed, fixed in 2257266. pack now rejects anything outside 1..=MAX_PRECISION up front, with test_ghbits_pack_rejects_out_of_range_lengths covering the empty and 13-character cases.

[mailletf]

Done in 2257266 — the output set is now built with HashSet::with_capacity(all.len()).