[Fedr]

HashSet<T> and HashMap<K, V> (and so FaceHashSet, VertHashMap, WholeEdgeHashMap and the rest) now allocate through MR::Allocator, like BitSet blocks since #7240: mimalloc explicitly, or std::allocator in Emscripten builds and with MRMESH_NO_MIMALLOC.

• MRMeshFwd.h forward-declares MR::Allocator for the aliases; MRPch/MRHashMap.h, the one header that includes phmap, includes MRAllocator.h for its definition. MRAllocator.h now includes config.h instead of MRMeshFwd.h, because the shared precompiled header must not see MRMESH_API that early.
• MR::Allocator<T> is now a class template deriving from mi_stl_allocator<T> or std::allocator<T>, instead of an alias for one of them, and MR_BIND_IGNORE: the bindings only see it as a template argument of containers. The C bindings are generated once, in the Emscripten image, and compiled on every platform. With the alias they spelled phmap::flat_hash_map<K, V> (Emscripten's std::allocator), which did not match MR::HashMap on native platforms. Now every container type names MR::Allocator<...> on all platforms.
• BitSet::bits() and BitSet::fromBlocks are bound again: they were hidden in BitSet blocks with the dependencies' non-override mimalloc; one mimalloc per process #7240 for the same Emscripten-vs-native allocator mismatch, not because mrbind ignores custom allocators.
• ParallelHashSet / ParallelHashMap are unchanged.

Checked locally: MRMesh, MRVoxels and MRViewer build with MSVC with no warnings, and in a test exe without malloc override, BitSet, HashMap (also a copy) and HashSet storage is in the mimalloc heap while plain malloc is not.

🤖 Generated with Claude Code