Pre-screen key length in the shared hash dispatch

[stephenberry]

What

Splits decode_hash_with_size into a thin wrapper that pre-screens the key length once and a per-type decode_hash_with_size_impl reader. The wrapper rejects any key whose length is outside [min_length, max_length] before dispatching:

template <uint32_t Format, class T, auto HashInfo, hash_type Type>
struct decode_hash_with_size {
   static constexpr auto N = reflect<T>::size;
   GLZ_ALWAYS_INLINE static constexpr size_t op(auto&& it, auto&& end, const size_t n) noexcept {
      if (n < HashInfo.min_length || n > HashInfo.max_length) [[unlikely]] return N;
      return decode_hash_with_size_impl<Format, T, HashInfo, Type>::op(it, end, n);
   }
};

Why

The in-place decoders (BSON, MessagePack, CBOR, CSV, TOML) call op(key.data(), key.data() + key.size(), key.size()) with the raw, unpadded key view. Several per-type readers dereference key bytes without bounding the read, so a foreign key shorter than the bytes a reader touches runs past the input buffer (ASAN heap-buffer-overflow):

• front_hash reads front_hash_bytes
• the sized unique_index path reads it[unique_index]
• mod4 / xor_mod4 / minus_mod4 read *it
• three_element_unique_index reads it[0]

Why one pre-screen suffices

Every reader's maximum read offset is provably below min_length (front_hash_bytes <= min_length, unique_index < min_length, and the mod4 family reads offset 0 where min_length >= 1), or it reads at most n bytes. A key whose length is outside [min_length, max_length] can never match a reflected key, so rejecting it up front bounds every reader's key access in one place. The individual readers therefore drop their per-read bounds checks.

The one exception is unique_per_length: its read offset is indexed by key length and unique_per_length_info maps absent lengths to 255, so a foreign key whose length falls in a gap of [min_length, max_length] would read it[255]. The length pre-screen can't catch that, so that reader keeps its own end check (commented as such).

Relationship to #2641

This generalizes the front_hash bound from #2641 to the whole reader set with a single mechanism, and supersedes that PR's front_hash-specific guard. If #2641 lands first I'll rebase to drop the now-redundant guard. CBOR's call-site length pre-filter (cbor/read.hpp) also becomes redundant and can be removed as a follow-up.

Tests / verification

Adds BSON tests for each reader (front_hash, sized unique_index, mod4, three_element_unique_index): a short/empty key on an exact-size heap allocation reproduces the over-read under ASAN, and valid documents still round-trip. static_asserts pin the selected hash so each case keeps exercising a distinct reader.

Verified locally under ASAN + UBSAN with zero regressions: bson 117, json 681, cbor 233, toml 384, csv 126, msgpack 51, plus the reflection/hashing suites. Neutering the pre-screen makes ASAN fire heap-buffer-overflow READ of size 4 (the front_hash reader), confirming the wrapper is the single bound.