Add PointCloudHashGrid: uniform-grid counterpart to PointCloudBVH

[rmrsk]

Summary

Closes #107

Background

PointCloudBVH (on the particle_soa_pr3 branch, PR #106) gives turnkey nearest-neighbor /
closest-point queries over a particle cloud, backed by a BVH. While finishing that work we prototyped
a uniform spatial grid as an alternative that circumvents the tree entirely, and found it clearly
faster on near-uniform clouds (~7× build, ~1.4× query). Issue #107 proposed promoting that prototype
into a first-class class mirroring PointCloudBVH. This PR does so.

Stacked on top of #106 (base branch particle_soa_pr3), since it mirrors PointCloudBVH and the new
example/docs reference it.

Solution

Adds PointCloudHashGrid<T, Meta>, which answers the same queries as PointCloudBVH and exposes
the same public interface — same Hit, same closestPoint / closestPoints / nearestNeighbor
/ nearestNeighbors / allNearestNeighbors, same O(N) brute-force reference queries, same
position() / metadata() / numParticles() accessors — so the two are drop-in interchangeable.

• Build: points are counting-sorted into a dense CSR bucket array keyed by integer cell
  coordinates (O(N), no tree). Cell size is derived from a target average occupancy (~1
  particle/cell by default).
• Query: an expanding-shell search outward from the query point's cell with an exact stopping
  rule — after searching Chebyshev radius R, the world region within the covered cell faces is fully
  searched, so once the k-th best distance is inside that bound no neighbor can be missed. Handles
  external queries and queries outside the grid box (clamped cell); k > 1 carries a sorted k-best
  set through the shells.

On a near-uniform 500k cloud the grid builds ~5× faster and queries ~2× faster than PointCloudBVH
(Examples/NearestNeighborHashGrid: build ~16 ms, query ~0.29 µs/pt, vs the BVH's ~76 ms / ~0.55).

Also included: EBGeometry.hpp include, Tests/InstantiateAll.cpp coverage, TestPointCloudHashGrid
(checked against an independent brute-force oracle in both precisions, including the outside-the-box
case), the Examples/NearestNeighborHashGrid example, and documentation (a PointCloudHashGrid
section in ImplemBVH.rst and full doxygen).

The two point-cloud examples were also renamed for clarity now that there are two backing structures:
ClosestPoint → ClosestPointBVH, NearestNeighbor → NearestNeighborBVH (that rename is part of
the base particle_soa_pr3 branch).

Side-effects

• The class is not a BVH: unlike PointCloudBVH it cannot be composed as a primitive inside an
  outer BVH/CSG union. It serves only point queries.
• The grid is bounded-domain: dense cells sized to the cloud bounding box, O(bboxVolume / h³)
  memory — fine for a compact cloud, wasteful for one sparse but spread over a large box.
• The performance win is density-dependent: a single global cell size only suits near-uniform
  clouds. For clustered / multi-scale clouds PointCloudBVH's density adaptivity is the better choice
  — documented in the class comments, ImplemBVH.rst, and the example README so callers can pick.

Alternative solutions

• Shared abstract base / concept for PointCloudBVH and PointCloudHashGrid so callers can
  select a structure polymorphically. Deferred — the two share an interface by convention here; a
  formal shared interface is a separate refactor (noted in Add a PointCloudHashGrid class: uniform-grid counterpart to PointCloudBVH for nearest-neighbor queries #107).
• True spatial hashing (unordered_map<cellId, bucket>) instead of a dense array, to bound memory
  to O(N) on unbounded/sparse domains. Deferred; the dense grid is the fast bounded-domain case and
  the natural first cut. Same query logic would apply.
• k > 1 fast path and a k=1 specialization mirroring the BVH's — not needed yet; the general
  k-best path is already fast for k=1.