Guard _create_instance_func with _constructing_mutex on shared-global (macOS hot-reload) builds

[reforia]

Bug

On macOS editor/debug builds with hot reload (MACOS_ENABLED && HOT_RELOAD_ENABLED, i.e. _GODOT_CPP_AVOID_THREAD_LOCAL), ClassDB::_create_instance_func races on the shared construction state and performs an unbalanced mutex unlock, causing intermittent (~50%) SIGABRT during off-main-thread instantiation (e.g. ResourceLoader.load_threaded_request() of a GDExtension resource, or any construction on a WorkerThreadPool thread):

BUG: Godot Object created without binding callbacks. Did you forget to use memnew()?
  (src/classes/wrapped.cpp, Wrapped::Wrapped(const StringName &))

…often followed by downstream instance-binding / TypedArray type corruption.

Full analysis in #1990.

Root cause

On this build the _constructing_* state is a shared global guarded by Wrapped::_constructing_mutex, not thread_local. The locking contract is:

• _pre_initialize<T>() (the memnew path) locks the mutex, then sets the construct info.
• Wrapped::Wrapped(const StringName &) consumes the globals and nulls them.
• _postinitialize() unlocks the mutex.

Since #1568 the 4.4+ create path uses manual _set_construct_info<T>() + placement-new instead of memnew (intentionally — p_notify_postinitialize lets the engine defer post-init, which memnew can't express). But that change dropped the lock memnew was providing via _pre_initialize, while _postinitialize() still unlocks. The macOS shared-global workaround (#1594) landed between #1568's authoring and its merge, so the gap went unnoticed.

Result, under concurrency:

1. Unguarded write — _set_construct_info<T>() writes the shared globals with no lock; a concurrent construction can clobber _constructing_class_binding_callbacks before the Wrapped ctor consumes it → nullptr → CRASH_NOW_MSG.
2. Unbalanced unlock — _postinitialize() unlocks a recursive_mutex this path never locked (UB), tearing down a critical section held by another thread.

_recreate_instance_func is unaffected — it already uses an explicit std::lock_guard.

Fix

Mirror _pre_initialize/_postinitialize on the 4.4+ path: lock before _set_construct_info, and balance the unlock in the deferred (no-p_notify_postinitialize) branch. The pre-4.4 path keeps memnew (which locks itself). Non-macOS and release builds compile out both #ifdef blocks — no behavior change. Nested memnew during a T constructor stays safe because the mutex is recursive.

Why the symptoms match

• Intermittent (~50%), timing-dependent → race in a sub-microsecond unlocked window.
• Only on threaded loads; synchronous main-thread load() never crashes → no interleaving, and a stray unlock() on an uncontended recursive_mutex is benign.
• macOS-specific → the shared-global branch is MACOS_ENABLED && HOT_RELOAD_ENABLED only; release/export templates use real thread_local.

Testing

Builds clean against the bundled test extension on the affected config:

cd test && scons platform=macos target=editor dev_build=yes

which instantiates _create_instance_func on the _GODOT_CPP_AVOID_THREAD_LOCAL path.

Fixes #1990.

[dsnopek]

I've attempted a different approach at fixing this issue in PR #1992

It makes sure we don't have an stray mutex.lock() and mutex.unlock() that we need to keep track of, which should be easier to maintain long-term

[dsnopek]

Superseded by #1992