Account for input hash vector in construction memory estimate

estimate_num_bytes_for_construction returned max(map_bytes, search_bytes),
but the input hash vector lives across both phases. The partitioned
external builder pushes the per-partition hashes (num_keys *
sizeof(hash_type)) into in_memory_partitions and only adds the build
estimate to its running 'bytes' counter, so the bytes < config.ram gate
underestimated true residency by num_keys * sizeof(hash_type) per
partition.

For hash128 (16B) plus the search-phase peak (~25B/key), peak per-
partition residency is ~41B/key while the gate believed ~25B/key, so
config.ram=2GiB actually allowed ~3.2GB resident. Adding the input
hashes outside the max makes config.ram match observed RSS.

Author: claude

include/builders/internal_memory_builder_single_phf.hpp

@@ -214,7 +214,13 @@ struct internal_memory_builder_single_phf {
             + num_keys * sizeof(uint64_t)                                        // hashes
             + table_size / 8;                                                    // bitmap taken
 
-        return std::max<uint64_t>(num_bytes_for_map, num_bytes_for_search);
+        // The input hash vector lives across both the map and search phases,
+        // so its footprint must be added outside the max, not folded into it.
+        uint64_t num_bytes_for_input_hashes =
+            num_keys * sizeof(typename hasher_type::hash_type);
+
+        return std::max<uint64_t>(num_bytes_for_map, num_bytes_for_search) +
+               num_bytes_for_input_hashes;
     }
 
 private: