fix(napi): guard JsDeferred against env teardown

[cuva]

Problem

JsDeferred carries a raw napi_threadsafe_function with no finalize callback and no teardown awareness: resolve()/reject() call it from arbitrary threads. When a deferred settles after (or while) its environment tears down — e.g. a #[napi] async fn future resolving after its worker thread terminated — it calls straight into a freed threadsafe function and the process dies with SIGABRT (abort ← uv_mutex_lock ← v8impl::ThreadSafeFunction::Push ← napi_call_threadsafe_function ← JsDeferred::resolve).

This is upstream napi-rs#2460.

Two adjacent defects in the same path are also covered:

• Node invokes leftover queue items with a null env while a threadsafe function closes during env teardown; napi_resolve_deferred dereferenced it.
• The execute_tokio_future panic-handler clone could settle a second time, calling into an already-released threadsafe function.

Fix

• The deferred (and its clones) share a DeferredHandle holding the threadsafe function as Mutex<Option<...>>. A settle take()s it, moving the release duty into the queued DeferredData; an env cleanup hook — registered after the threadsafe function's own teardown hook, so LIFO order runs ours first — abort-releases it before Node finalizes it. Whichever locks first wins; the loser observes None and drops its resolver instead of touching freed memory.
• The lock is held across the napi_call_threadsafe_function / abort-release calls, so env teardown cannot finalize the threadsafe function while a settle on a foreign thread is inside it (an atomic flag alone cannot close that window).
• The threadsafe function's finalize callback unregisters the cleanup hook and frees the shared weak, so per-deferred bookkeeping is reclaimed as soon as the promise settles — nothing accumulates.
• napi_resolve_deferred returns early on the null-env teardown invocation.

Verification

Stress harness (macOS arm64, Node v22.22.2): spawn a worker that starts 32 createReferenceOnFunction calls (100 ms tokio sleep each, execute_tokio_future_with_finalize_callback path), terminate the worker while they are in flight, keep the addon alive in the main env so the shared tokio runtime survives and the futures resolve into the torn-down worker env.

build	result
base (unfixed)	8/8 batches SIGABRT, faulting stack identical to the production crash
this branch	0/12 batches crashed (3,072 resolve-after-teardown events)

Memory churn (hook/box reclamation): 600k settled deferreds in one process — RSS 52 → 107 MB during warmup of the first 200k, then flat (111 → 111 MB) across the following 400k.

Also passing: cargo check (default / tokio_rt,deferred_trace,napi9,compat-mode / noop), clippy, and the @examples/napi suite (230 tests).