Restore aligned bucket loads

[sleeepyjack]

Restore one storage-owned, aligned whole-bucket load for all probing operations, enabling vectorization up to 32 bytes without changing hash-table layouts or defaults.

Changes

• Derive storage alignment from the bucket stride: max(alignof(T), gcd(32, BucketSize * sizeof(T))). This preserves odd bucket sizes and natural alignment without adding per-bucket padding.
• Implement the aligned load in bucket_storage_ref::load_bucket(index) using the existing storage implementation file. All probing schemes are assumed to produce bucket-aligned slot indices. General public slot-indexed access and custom storage access remain supported.
• Route all 20 probing read sites through the same whole-bucket accessor, including scalar/cooperative lookups, count, insertion, erase, map updates, and retrieve/for_each. There are no per-operation load modes or narrower-load exceptions.
• Restore the whole-bucket loading contract used before Refactor bucket storage to 1D layout for improved performance #694, while retaining the current flat slot representation.
• Document borrowed/shared-memory alignment requirements and add alignment, boundary, allocator, wraparound, and custom-equality tests.

No CG/bucket defaults, cache intrinsics, atomics, or synchronization are changed.

Performance

NVBench on RTX PRO 6000 Blackwell Max-Q (SM120), CUDA 13.1.115, GCC 14.3.0, CCCL 3.5.0, Release/C++17. Baseline: 532795b81e72e3fe4ce2b26eb0c5abc8abb1e2b4.

Representative results at LF 0.5 and 50% matching independently shuffled queries. GPU times are medians of nine paired runs, with 100 samples per run.

Operation	Entries	Baseline (ms)	Candidate (ms)	Speedup
Set contains, 32-bit keys, DH C1/B8	1M	0.0389504	0.0204800	1.902x
Map find, 64-bit keys and values, LP C2/B4	20M	1.679580	2.442629	0.688x

This version is not regression-free. The map-find case reproducibly takes 45.43% more time. That remains an open performance issue; the bucket-loading API stays uniform.

The new main sweep covers 504 set/map/mixed-map cases: 32/64-bit keys, mixed payload widths, 1M/20M entries, LF 0.5/0.8/0.9, and contains/find/insert. It has 58 initial >2% slowdown flags. An additional 32 multiset count/retrieve cases (C4/B2 and C2/B4, multiplicities 1/16, LF 0.5/0.9) have no >2% slowdown flags. These sweeps use five paired runs and 30 samples/run.

Earlier results from the selective-load implementation are superseded and are not performance claims for this version.

Codegen

• Fully consumed 32-byte buckets emit LDG.E.ENL2.256 on SM100/120.
• Real SM120 C1/B8 int32 and C1/B4 int64 contains kernels now emit 256-bit bucket loads. C2/B4 int64 multiset count does as well.
• Real 64-bit-key multiset retrieve kernels emit 256-bit loads for C2/B4 and 128-bit loads for C4/B2, without spills.
• The inspected kernels have no new spills. Key-only map lookup can still contain a mixture of scalar and wide loads chosen by the compiler.
• SM80/90 checksum probes remain scalar; no older-GPU speedup is claimed.

Validation

• 597 tests passed across utility, static set/map/multiset/multimap, and dynamic map.
• Memcheck, synccheck, and racecheck: 357 assertions in 21 cases; no errors or hazards.
• All 13 static-container examples built and ran.
• The repository map-update benchmark completed eight insert_or_apply smoke cases.
• CUDA 12.0/GCC 12.5 SM70 smoke compilation passed; codegen inspected for SM80/90/100/120.
• Formatting and copyright hooks passed.

Runtime measurements are limited to one SM120 GPU. Doxygen was unavailable. The performance matrix is not exhaustive; CI and older-GPU runtime validation remain outstanding.