[FEA]: Migrate materialized bucket loads to cudax cuco #11334

Follow-up to the storage discussion in #11095. Related to the upstream migration tracker #9981.

CCCL's __slot_storage_ref::operator[] returns a cuda::std::span over the stored slots. Upstream cuco returns a materialized bucket array by value and defines storage alignment for vector loads.

Consequently, const auto bucket_slots = storage_ref[index] copies only a view in CCCL. This surfaced in #11095: passing an element to a callback exposes the stored slot instead of the documented copy. Fixing that callback locally still leaves the broader bucket-load migration outstanding.

We should migrate materialized bucket reads and enable vectorized loads where the layout and alignment permit:

• Return an owning bucket value from a read operation and audit the probing callers that consume it. Retain mutable slot access for updates and iterators.
• Handle alignment explicitly, preserving supported externally supplied storage with a safe fallback where wider loads are unsuitable.
• Add coverage for copy semantics and inspect generated PTX/SASS. Benchmark multiple bucket sizes and prioritize workloads with longer probe sequences: near-full tables, unsuccessful lookups, and duplicate-heavy multiset/multimap workloads as those containers are migrated.

The earlier port comparison reported near parity for unique-key maps, including an occupancy sweep up to 0.9, but used the default CG size 4 and bucket size 1. It did not cover larger buckets or multiset/multimap workloads, nor isolate bucket materialization.

Near-full tables and duplicate-heavy multiset/multimap workloads can require longer probe sequences and more slot scanning. Vectorized bucket loads may therefore provide a more visible benefit in those cases by reducing the load instructions needed to scan each bucket. The existing benchmark parity does not settle that question; these workloads should guide the code-generation and performance evaluation.