fix(runtime): interrupt spinning workers and add an awaitable Worker disposal barrier

[smarcd]

Problem

Worker.terminate() only sets a flag and wakes the worker's event loop. A
worker that is spinning in JavaScript or WebAssembly never returns to that
loop, so it keeps running, and keeps writing to any SharedArrayBuffer it
shares, indefinitely. There is also no way to wait until a worker has actually
stopped executing, which an embedder needs before reusing memory the worker
could still write.

There is no existing issue for this. A minimal repro: start a worker that
increments a shared counter in a while (true) loop (or in a Wasm loop),
call terminate(), and observe that the counter keeps increasing.

Changes

Interrupting a worker

• terminate() now also interrupts the worker's isolate (V8
  TerminateExecution), so spinning JS and Wasm stop.
• New Worker[Symbol.asyncDispose](): requests termination and resolves only
  once the worker's JavaScript, and the native tasks in its runtime's blocking
  pool (nonblocking FFI calls, N-API async work, blocking reads), have stopped.
  While waiting it re-requests the stop every 10ms, because V8 can discard a
  termination (see below). Plain terminate() stays a single, non-blocking
  request.
• A host stop is recorded in a sticky isolate slot
  (ExternalExecutionTermination), so node:vm timeouts and other local
  cancellations cannot clear it.

Keeping a stop from being lost or caught

• V8 reports and clears any exception thrown by a promise hook that runs while
  C++ creates a promise (NativeContext::RunPromiseHook), termination
  included. Module evaluation checks the sticky slot afterwards and re-raises
  the stop.
• V8's ThrowException clears a pending termination, so an op that failed
  because its isolate was terminating turned the stop into a catchable error.
  The #[op2] error path (throw_op_error) and throw_js_error_class now
  leave a pending termination in place.
• Lazy and synthetic module loading, require(esm) (mod_evaluate_sync) and
  dynamic import() of lazily loaded modules propagate termination instead of
  panicking on unwrap(), reporting it as an ordinary JS error, or dropping it.

Teardown with native code still running

• A stopped worker is dropped as before, which releases its message port,
  locks, listeners and child workers promptly. Only FFI state that a running
  native call may still use (UnsafeCallback trampolines and libffi Cifs,
  and loaded libraries) is kept until the worker's blocking pool drains.
  Libraries are unloaded before callbacks are freed.
• Cross-thread callbacks are cancelled during shutdown, while the isolate is
  still alive. A callback invoked afterwards, including from a library's unload
  destructor, returns a zero value without entering V8.
• FFI callbacks no longer panic across the C boundary when they throw or are
  interrupted with an isize/usize/struct result, or when converting their
  return value fails. The libffi return slot is zeroed instead.
• N-API threadsafe-function queue slots are freed, and every blocked caller is
  woken, when shutdown discards queued calls. Previously a blocking call on a
  full queue could hang worker teardown.

Tests

Each fix has a regression test that was committed failing before the fix.
Covered: core module-loading interruption cases, VM-timeout and host-stop
interaction, Worker disposal with spinning Wasm, a promise-hook-swallowed stop,
and native writes into shared memory. Also FFI callback lifetime during
disposal, prompt host-state release while a native call runs, library-unload
callbacks in both creation orders, wide and interrupted callback results, and
N-API full-queue disposal.

Local runs on macOS arm64: deno_core (494 passed), deno_ops (126), the
FFI and N-API integration suites, unit::worker_test, the Node vm unit
test, the worker startup spec, plus ./x fmt and ./x lint.

Known limitations

• Plain terminate() sends one interrupt, so a stop that V8 discards in a
  promise hook can still leave a worker running. Symbol.asyncDispose is the
  reliable stop.
• Disposal does not cover descendant workers, detached OS threads or threads
  owned by native libraries, and it can wait indefinitely for a blocked native
  call. Every stopped worker's thread now stays alive until such calls return.
• Native code given a raw pointer into JS memory (N-API buffer info, FFI raw
  pointers) can still write after the isolate is dropped. This is unchanged
  from before.

AI disclosure

This PR was written with AI assistance (Anthropic Claude via Claude Code, with
OpenAI Codex used as an independent reviewer). A human directed the work, and
every change was reviewed and tested as described above.

🤖 Generated with Claude Code

[smarcd]

This is still a draft. I pushed CI-readiness fixes in 5908f5a (a Miri gate for a V8-backed test, plus Windows-safe paths and wider timing margins in a new FFI test). The ci and pr workflows show action required: they need a maintainer to approve the workflow run for a first-time contributor before they'll execute. Locally, the PR title lint, format, lint and jsdoc_checker all pass, along with the deno_core, deno_ops, FFI, N-API and Worker suites and the deno_core doc tests.

[CLAassistant]

All committers have signed the CLA.