runtime: #8416 made dynamic Function errors unwind, but only js_closure_call1 is C-unwind — the rest of the dispatch family aborts (nightly bun_ffi_stage1 red) #8463

Nightly full-tier run 32332070993 (526e0b5) fails cargo-test on tier1_every_ffi_type_against_test_dylib (crates/perry/tests/bun_ffi_stage1.rs:331): the compiled binary completes its FFI checks then dies with

thread '<unnamed>' panicked at library/core/src/panicking.rs:
panic in a function that cannot unwind
thread caused non-unwinding panic. aborting.

Cause: #8416 ("let dynamic Function errors unwind") converted js_closure_call1 — and only the OUTER signature of js_closure_call2 — to extern "C-unwind". The rest of the closure dispatch family kept plain extern "C", which installs Rust's abort-on-unwind shim: js_closure_call0, call2's inner transmuted fn type, call3…callN, dispatch_with_arity's per-arity transmutes (the COMMON arity-adjusted path), js_closure_call_array, js_closure_call_apply_with_spread, the direct-call-site cache, js_function_bind. Any JS exception that now unwinds (per #8416's intent) through one of those edges aborts instead of reaching the generated caller's landing pad. Linux-visible (same shape as #8416's original symptom); does not reproduce on macOS.

Fix: mirror #8416 across the whole family — every closure-dispatch entry point and transmuted call edge becomes extern "C-unwind". Registration entry points (js_register_closure_*) stay extern "C" (no user code runs under them).

Validated locally (macOS): 64 closure unit tests, all 3 bun_ffi_stage1 tests, and the #8416 regression suite (function_apply_dynamic_args_eval_surface) green. Linux verification rides the PR's scoped CI (the suite file is named in the diff).