NIF symbol collision: loading QuickBEAM.Native before LazyHTML breaks CSS selector parsing on macOS ARM64

[Valian]

I found a NIF conflict between QuickBEAM and lazy_html on macOS aarch64. If QuickBEAM.Native is loaded (via dlopen) before LazyHTML.NIF initializes, LazyHTML.query/2 permanently fails with RuntimeError: failed to parse css selector. Other LazyHTML functions (from_document, to_tree) are unaffected.

Minimal reproduction:

# QuickBEAM NIF loads first — breaks LazyHTML
Code.ensure_loaded!(QuickBEAM.Native)

"<div class=\"x\">test</div>"
|> LazyHTML.from_document()
|> LazyHTML.query("[class=x]")
# => ** (RuntimeError) failed to parse css selector

# LazyHTML initializes first — everything works
"<div class=\"x\">test</div>"
|> LazyHTML.from_document()
|> LazyHTML.query("[class=x]")
# => #LazyHTML<1 node>

Code.ensure_loaded!(QuickBEAM.Native)

"<div class=\"x\">test</div>"
|> LazyHTML.from_document()
|> LazyHTML.query("[class=x]")
# => #LazyHTML<1 node>  (still works)

The load order matters: the conflict only happens when QuickBEAM's NIF .so is dlopen'd before LazyHTML's CSS selector parser initializes. This causes mix test to always fail (67/207 tests) because the BEAM loads all compiled modules eagerly and QuickBEAM.Native happens to load first. Individual test files pass fine.

Does not reproduce on Linux x86_64 (Ubuntu 24.04 CI) — only macOS ARM64. I suspect the precompiled macOS NIF binary exports symbols that collide with lazy_html's lol-html CSS selector parser. The Linux binaries likely have stricter symbol visibility.

Tested with:

• QuickBEAM 0.8.1 (also tried 0.10.6, same issue)
• lazy_html 0.1.10 and 0.1.11
• macOS 14.5 (Darwin 23.5.0), Apple Silicon
• OTP 28 / Elixir 1.19