[Windows][V8] Prebuilt V8 causes an ODR violation in MSVC STL std::unordered_map instantiations

Summary

Linking Wasmer 7.4.0 with its V8 backend into an MSVC application can corrupt an unrelated std::unordered_map<unsigned, unsigned> from another static C++ library.

The V8 archive emits MSVC STL template functions using V8's Wang32 specialization of std::hash<unsigned>. The host library emits the same decorated template symbols using MSVC's normal FNV-1a hash. The linker can select incompatible implementations for insertion and lookup, so the same key is placed in and searched for in different buckets.

Environment

• Windows x86_64, static release MSVC CRT
• Rust 1.98.1, x86_64-pc-windows-msvc
• Wasmer 7.4.0 with v8-default
• wasmer-wasix 0.704.0 with v8
• wee8 11.9.7 / V8 13.6.233.17

Evidence

• The host crashes with 0xc0000005 inside the unrelated library's unordered_map consumer.
• A dump contains every key twice: one entry has the intended value and one has a default value inserted after lookup misses the original bucket.
• Disassembly of deoptimizer.obj in libv8prefixed.a shows Wang32 in an MSVC unordered_map<unsigned, unsigned>::_Try_emplace instantiation. Its decorated symbol matches the host library's FNV-1a instantiation.
• Removing the Wasmer/V8 feature eliminates the corruption across repeated startup tests; the other library and its version are unchanged.

Relevant sources:

• wee8 Windows build: https://github.com/wasmerio/v8-custom-builds/blob/11.9.7/build.ps1
• V8 hash specialization: https://github.com/v8/v8/blob/13.6.233.17/src/base/hashing.h#L363-L367

Expected behavior

Linking Wasmer's V8 backend must not change the behavior of MSVC STL containers instantiated by unrelated host libraries.

Could the Windows wee8 archive avoid applying V8's hash specialization to fundamental types, hide the conflicting STL template symbols, or isolate V8 behind a DLL/C ABI boundary?