Follow-up to #66, #461, and #462. The MessagePort close-lifecycle audit found broader native task cleanup debt: ScriptExecutionContext creates EventLoopTask allocations whose captured references are released only by performTask/deleteEventLoopTask. Worker ticks stop before final GC; VirtualMachine.deinit does not drain or cancel remaining event-loop payloads. EventLoop.deinit frees containers but not queued CppTask captures/concurrent nodes. enqueueTaskConcurrent and its batch variant also return on has_terminated without releasing already-allocated task ownership, despite a comment claiming no leak.
The targeted #462 fix prevents locally generated teardown close drains from entering a stopped loop; it does not solve remote work already queued during shutdown. Implement an explicit cancellation/ownership protocol, destroy thread-affine native captures on their owning thread, synchronize producer admission with shutdown, and never execute user JavaScript in a stopped VM. Avoid freeing arbitrary captures inside the global contexts-map lock (destructors may post/close recursively). Add bounded repeated-worker tests with remote queued native work, exact destructor/ownership counters where feasible, natural process exit, and no relaxed memory thresholds. Preserve live peer notifications and existing NAPI finalizer ordering. This issue is an audited gap, not a claim that all native queued task types are safely cancellable today.