…4695)

Native addons built against the legacy Node.js `NODE_MODULE` / `nan` ABI
(such as `better-sqlite3`) link against V8 C++ internals that Deno does
not expose. Since #34683, Deno rejects them with a clear
`UnsupportedLegacyAddon` error instead of crashing — but the error
offered no guidance on what to do next.

This adds an actionable fix-suggestion in `runtime/fmt_errors.rs`
(`get_suggestions_for_terminal_errors`) that fires on the legacy-addon
error and points users at Node-API alternatives:

- **`better-sqlite3`** is special-cased (the error message includes the
`.node` path) to recommend the built-in `node:sqlite` module and the
`npm:libsql` / `npm:@libsql/client` packages (the latter expose a
`better-sqlite3`-compatible API).
- Any other legacy addon gets a generic hint to switch to / migrate the
addon to Node-API.

### Why not actually run `better-sqlite3`?

Running these addons would require Deno to expose V8's C++ API and
node:: helper symbols and to be ABI-compatible with the V8 the addon was
built against. Deno's `rusty_v8` is several major V8 versions ahead of
the V8 that prebuilt `better-sqlite3` binaries target (Node 20, V8
11.x), so exported symbols would not be ABI-compatible. That is a large,
separate effort; this PR improves the failure UX in the meantime,
directly addressing the most-reported package in the issue.

### Test

`tests/specs/run/node_addon_legacy_suggestion/` exercises both the
`better-sqlite3`-specific and the generic suggestion by throwing the
error string (no native build needed, mirroring the existing
`node_addon_bindings_suggestion` spec test).

```
cargo test --test specs -- run::node_addon_legacy_suggestion
```

Refs #26034

Closes denoland/divybot#408

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>

…exe (#34696)

## Problem

Loading uWebSockets.js (and similar prebuilt native addons) on
**Windows** fails with a cryptic error:

```
error: Uncaught (in promise) Error: This version of uWS.js supports only Node.js LTS versions 16, 18 and 20 ...
TypeError: LoadLibraryExW failed
```

The "supports only Node.js LTS" text is uWS's own fallback message; the
real error is `LoadLibraryExW failed`, which tells the user nothing
actionable.

## Root cause

uWS's prebuilt Windows `.node` (`uws_win32_x64_{108,115,127}.node`) is
**not a Node-API addon**. Inspecting its PE import table (`objdump -p`)
shows a **regular, non delay-load import of `node.exe`** that pulls in:

- raw **V8 C++ ABI** symbols (`v8::Object::New`, `HandleScope`,
`FunctionTemplate`, …)
- **Node.js internals** (`node::MakeCallback`,
`node::AddEnvironmentCleanupHook`, `node::GetCurrentEventLoop`)
- **libuv** (`uv_run`, `uv_async_init`, …) and **zlib**

The Windows loader resolves an import of `node.exe` by module name at
`LoadLibraryExW` time, so it only succeeds when the host process is
literally named `node.exe`. Loaded into `deno.exe` (or any other host —
this is also why it breaks in Node SEA, Bun and Electron), the import
can't be satisfied and the load fails.

Deno cannot make such an addon work: it doesn't (and can't) export V8's
C++ ABI, Node's internal C++ API, or a real libuv event loop. The only
correct outcome is a clear diagnostic.

## Fix

Mirrors the legacy V8/nan addon diagnostic added in #34683.

- New dependency-free, bounds-checked PE import-table reader in
`ext/napi/pe.rs`. `imports_node_executable()` parses the **regular**
import directory and checks for a `node.exe` import (case-insensitive).
It is unit-tested with a synthetic PE builder and was validated against
the real uWS binaries (output matches `objdump` exactly).
- New `NApiError::UnsupportedNodeBinaryAddon`. On Windows, when
`Library::load_with_flags` fails, the addon is inspected; if it imports
`node.exe` directly, Deno now reports:

> Cannot load native addon at <path>: it links directly against
the Node.js binary (node.exe) and relies on the V8 C++ ABI, Node.js
internals and/or libuv exported by that executable, none of which Deno
provides. Only Node-API (N-API) addons are supported. ...

**Delay-loaded** `node.exe` imports (the node-gyp default, redirected to
the host at runtime via `win_delay_load_hook`) are intentionally ignored
— those resolve against the host's exported N-API symbols and work fine
in Deno.

## Testing

- `cargo test -p deno_napi --lib pe::` — 4 unit tests
(real-binary-shaped fixtures + malformed input).
- `cargo clippy -p deno_napi --all-targets` and `cargo clippy -p
deno_napi --target x86_64-pc-windows-msvc` both clean (the new
load-failure arm is Windows-only).

Refs #25956

Closes denoland/divybot#409

---------

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>