[memory]: Memory breakdown reporting and estimation functionality have to handle Hugepage allocations rounded to 2MB

> This is the fallout from `IndexBuilder` storing a live handle rather than a builder: the estimator has no way to know which allocator was configured, so it has to hardcode one. The result is that `svs_index_builder_estimate_memory_dynamic` is wrong for `SVS_ALLOCATOR_KIND_HUGE_PAGE` (2 MiB rounding is unaccounted for) and wrong for any custom allocator. `dispatch_vamana_memory_estimate` (~line 159 of `dispatcher_vamana.cpp`, unchanged here) is allocator-blind entirely — it still uses `SimpleDataBuilder{}`.
>
> Note that if the motivation for defaulting to `lib::Allocator` was to make the estimate line up with `within_1pct(tracker.live_bytes, memory_usage)` in the new tests, that's fixing the estimator's inaccuracy by degrading the runtime. Threading the *kind* through instead fixes both.

_Originally posted by @ethanglaser in [#380](https://github.com/intel/ScalableVectorSearch/pull/380/changes#r3972251277)_

Start by reading IndexBuilder and the svs_index_builder_estimate_memory_dynamic entry point, then inspect dispatch_vamana_memory_estimate around line 159 of dispatcher_vamana.cpp and its use of SimpleDataBuilder. Compare the estimator with the configured allocator behavior. Done means hugepage allocations include 2 MiB rounding and custom allocator estimates are no longer allocator-blind without degrading runtime behavior.

Written by the indexing model from the issue text.