Honor the initial hash reservation to avoid repeated rehashing during storage conversion #189

Hash::reserve does not reserve the requested bucket capacity on an empty map. In src/hx/Hash.h, expandBuckets sets newCount to 2 when bucketCount is zero, but only runs the growth loop in the else branch. An initial reserve(100000) therefore allocates two buckets.

I reproduced this against checkout 3c6b55c on Linux x86_64 through WSL, using Haxe 4.3.3, HXCPP_M64 and the current internal Hash implementation:

auto map = new hx::Hash<hx::TIntElement<int>>();
map->reserve(100000);
// map->bucketCount is 2

Inserting 100000 entries after that reservation caused 14 further bucket-count changes. All 100000 entries were present afterward.

This is an internal reservation path, not a claim that Haxe Map exposes a reserve method. TConvertStore calls reserve(getSize()*3/2) on a fresh map before copying every entry, so changing a populated map's value storage can pay for repeated bucket allocations and rehashes despite knowing the size in advance.

Run the capacity-growth calculation after selecting the initial bucket count, so the first reservation is large enough. Keep overflow checks and the existing load-factor/growth policy. Check empty and small reservations as well as large maps.

Measure populated IntMap and StringMap storage conversions, such as integer values becoming Dynamic or floating values, with elapsed time, bucket growth count, allocated bytes and GC activity. Keep entry-by-entry allocation separate when reporting gains; fixing reservation will not remove that remaining cost.

This is a small, contained candidate for avoiding repeated work. No runtime fix or before/after speedup has been measured yet. Related: #151 for repeatable performance coverage.