Fixes the Windows panic reported in #35990:

thread 'main' panicked at ext\napi\node_api.rs:947:5:
assertion failed: self.is_closed.compare_exchange(false, true, Ordering::Relaxed, Ordering::Relaxed).is_ok()

napi_release_threadsafe_function with napi_tsfn_abort freed the TsFn
regardless of the remaining thread_count. When more than one thread still held
the function, aborting spawned the drop immediately, freeing the box out from
under the other reference holders. Those threads were left with a dangling
pointer, and a later release from one of them could deref the freed box and
spawn a second drop of the same allocation, producing a use-after-free and a
double free. On the second drop the is_closed compare-exchange in TsFn::drop
fails and the assertion panics.

Abort now only marks the function as closing (rejecting pending and future calls
and waking any callers blocked on a full queue). The box is freed exactly once,
when the last thread releases it and the thread count reaches zero. This matches
Node.js semantics, where abort stops further calls but destruction still waits
for every acquired thread to release. The non-abort path is unchanged: it
already only freed on the final release.

The reproduction is inherently timing and allocator dependent (the second drop
only trips the assert once the freed memory is observed as reusable), which is
why it surfaced on Windows under a real addon rather than deterministically. The
added regression test creates a tsfn with initial_thread_count = 2, aborts
from one thread while a second reference is still outstanding, and asserts the
finalizer runs exactly once.