HeadpartExtended.dll crash: null actor pointer in MyHooks::updateFace3d (background queue thread)

=== CRASH DETAILS ===
Fallout 4 v1.10.163
Unhandled exception "EXCEPTION_ACCESS_VIOLATION"
Location: HeadpartExtended.dll+00BD1D6
Instruction: mov rax, [rax+0x3B8]
Source: main.cpp:319, void MyHooks::updateFace3d(RE::Actor *)
Crash Thread ID: 11944
Access Violation: Tried to read memory at 0x0000000003B8 (rax = 0x0, i.e. null actor pointer)
Exception Flags: 0x00000000 (Continuable)

Call stack (top frames):
[0] HeadpartExtended.dll+00BD1D6  MyHooks::updateFace3d(RE::Actor*)         main.cpp:319
[1] HeadpartExtended.dll+002961C  MyHooks::callNextInQueue(void)            main.cpp:627
[2] HeadpartExtended.dll+0062920  std::invoke<void(*)(void)>(...)
[3] HeadpartExtended.dll+004A429  std::thread::_Invoke<...>(...)
[4] HeadpartExtended.dll+01C935F  __crt_internal_free_policy::operator()(...)

=== ANALYSIS ===
The crash occurs on a background worker thread (std::thread) processing a
queue of pending face-update jobs via callNextInQueue -> updateFace3d.
The Actor* passed to updateFace3d is null, causing the read at offset 0x3B8
to fault.

The mod's own debug log (HeadpartExtended.log) for the crashing thread
(11944) confirms this: its final entry before the crash is
"call next in queue" with NO subsequent log lines (no Reset3D, no NPC
lookup, no "is known"/"is a preset" checks) - meaning the thread dequeued
an item and crashed immediately trying to use the actor pointer, before
reaching any point where it would normally log the actor's identity.

This looks like a stale/invalidated Actor* being left in the queue -
e.g. an actor disabled, unloaded, or deleted between being enqueued and
being processed by the worker thread, with no null-check/validity check
before use in updateFace3d.

=== LOG EXCERPT: thread 11944 activity leading up to crash ===
(full HeadpartExtended.log is ~1.16MB; this is the relevant excerpt)

[15:40:34.971] [11944] [D] call next in queue
[15:40:34.971] [11944] [D] Reset3D called for 001FE328
[15:40:34.971] [11944] [D] call next in queue
[15:40:34.971] [11944] [D] DoOnQueueMe() Called
[15:40:34.971] [11944] [D] 3500D5CC_REF was found
[15:40:34.971] [11944] [D] 3500D5CC_Act was found
[15:40:34.971] [11944] [D] FF007697_NPC was found
[15:40:34.971] [11944] [D] 4F03A8FB_RootNPC was found
[15:40:34.971] [11944] [D] 4F03A8FB_RootNPC is known
[15:40:34.971] [11944] [D] FE05886C_headpart removed from 3500D5CC
[15:40:34.971] [11944] [D] 3500D5CC_Act is known
[15:40:34.971] [11944] [D] FE05886C_headpart added to 3500D5CC
[15:40:34.971] [11944] [D] FF007697_NPC is a preset
[15:40:34.971] [11944] [D] FF007697_NPC is a preset
[15:40:34.971] [11944] [D] Reset3D called for 3500D5CC
[15:40:36.651] [11944] [D] call next in queue
[15:40:36.651] [11944] [D] Reset3D called for 1CC1E23F
[15:40:36.732] [11944] [D] call next in queue
[15:40:36.732] [11944] [D] Reset3D called for 1CC1E240
[15:40:38.453] [11944] [D] call next in queue
--- thread 11944 has no further log entries; crash occurs at 15:40:40 ---

=== SYSTEM CONTEXT ===
Process Uptime at crash: 01:22:52
Heavily modded load order (700+ plugins), multiple worker threads
(11944, 16276, 9104, etc.) concurrently hammering the same
Attach()/lock/unlock cycle on other actors at the same time, suggesting
high queue throughput/contention may make the race condition easier to
hit.

This crash has been reproduced across at least two other, unrelated
instances (different hairstyle mods, different NPCs) where the same
background queue eventually led to a crash deeper in cloth-physics
attachment code (hclClothInstance::setTransformSet) rather than at the
null-actor-pointer stage itself - consistent with the same root cause
surfacing at different points depending on timing.