Captured a full backtrace via lldb -k (see prior CI commit). The smoking gun:

  frame BabylonJS#5: ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED

  frame BabylonJS#6: napi_delete_reference at hermes_napi_reference.cpp:113

  frame BabylonJS#7: Napi::Reference<...>::~Reference at napi-inl.h:3262

  frame BabylonJS#8: Napi::ObjectReference::~ObjectReference

  frame BabylonJS#10: Babylon::Polyfills::Internal::URL::~URL at URL.h:10

  frame BabylonJS#12: Napi::ObjectWrap<...URL>::FinalizeCallback at napi-inl.h:4963

  frame BabylonJS#13: napi_env__::shutdown at hermes_napi.cpp:214

  frame BabylonJS#16: hermes::vm::Runtime::~Runtime

Root cause: Hermes's napi_env__::shutdown() iterates refListHead_ and delete ref; one at a time. It only sets ref->deletionPending_ on the *current* ref before its finalize_cb fires. If the finalizer transitively destroys a node-addon-api wrapper (Napi::Reference / Napi::ObjectReference) whose underlying napi_ref was already deleted earlier in the same loop, napi_delete_reference reads ref->deletionPending_ from freed memory and proceeds to delete ref again -> double-free.

The exact path: URL (an ObjectWrap subclass) has a Napi::ObjectReference member m_searchParamsReference. addReference prepends to the linked list, so m_searchParamsReference's ref is processed BEFORE URL's wrap ref. When URL's wrap finalizer runs delete this, ~URL destroys m_searchParamsReference, whose destructor calls napi_delete_reference on the already-freed sibling ref.

macOS libmalloc detects this (malloc: *** error for object 0x...: pointer being freed was not allocated -> SIGABRT). Linux glibc and Windows CRT happen to miss it.

Fix: PATCH Hermes shutdown() to mark ALL refs deletionPending in a pre-pass BEFORE iterating. Apply as a FetchContent PATCH_COMMAND via the new ApplyPatchIfNeeded.cmake helper (idempotent — uses git apply --check --reverse to detect already-applied state across reconfigure).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>