Upgrade reported Node.js version to 26.3.0 - #31818

The `NODE_MODULE_VERSION` 137→147 bump breaks `test/js/third_party/duckdb/duckdb-basic-usage.test.ts` on every non-skipped platform (9 variants in build #60774, not listed under "Known-unrelated failures"). The pinned `duckdb@1.3.1` package uses `@mapbox/node-pre-gyp`, which keys prebuilt downloads on `process.versions.modules`; there's no `node-v147` prebuilt for that release, so install falls through to a source build that fails in CI. Add an ABI-147 skip alongside the existing musl / win32-ar

The two `test/js/node/process/dlopen-*.test.ts` files build inline V8-API addons via node-gyp with plain `bunEnv`, and were not updated for the Node 26 header bump — they're failing in Build #60774 on macOS (aarch64/x64) and Windows (x64/x64-baseline/aarch64), and aren't in the known-unrelated list. They need the same env treatment this PR already applies in `test/v8/v8.test.ts` and here in `node-napi-tests/harness.ts`: delete `CC`/`CXX` from the env, add `-std=gnu++20` / `-std=c++20` to `CXXFLA

The Bun-pushed branch of `~HandleScope` (lines 65-70) pops the Bun scope stack and clears its buffer but never restores the isolate's `HandleScopeData`. If `Extend` ran while this scope was current (e.g. an addon's inline `Local::New` inside the `Array::Iterate` callback), `data->limit` is left pointing into the now-cleared buffer; the next addon-side inline `v8::HandleScope` snapshots that stale limit as `prev_limit_`, and on close `DeleteExtensions` → `deleteGrantsBack(stale_limit)` runs again