feat: port test_cannot_run_js to CTS

[kraenhansen]

Summary

Ports test_cannot_run_js from node/test/js-native-api/ to the CTS.

• Builds two addons from the same C source (test_cannot_run_js with NAPI_VERSION=10, test_pending_exception with NAPI_VERSION=9) to cover both code paths in the finalizer
• Verifies that when a finalizer tries to access JS during environment shutdown, napi_get_named_property returns napi_cannot_run_js (v10+), napi_pending_exception (v9), or napi_ok if the event loop is still running

Upstream source: https://github.com/nodejs/node/tree/main/test/js-native-api/test_cannot_run_js

Test plan

• npm run addons:configure && npm run addons:build — both addons compile cleanly
• npm run node:test — all 56 tests pass

🤖 Generated with Claude Code

[kraenhansen]

This fails on Node v20, we might want to just remove that from the test matrix as active support ended 22 Oct 2024?

[kraenhansen]

CI fails on Node.js v20 with SIGSEGV because Node-API version 10 is not fully supported on v20 — the fix landed in nodejs/node#55676 (v22.14.0+, never backported to v20).

Blocked on #37 (dropping Node v20 from CI).

[bavulapati]

We can use the napiVersion and skipTest primitives from #46 to skip this test when napi version < 10

[bavulapati]

let's split this into two tests. so that we can only skip test_cannot_run_js when napiVersion < 10. We did the split similarly in #44

[kraenhansen]

I see we did that 🤔 My hope is that we can keep these tests very close (almost verbatim) to the original source as this makes it easier to automatically spot regressions in coverage.

And then have follow-up PRs with refactors, which are easy to revert in isolation.

I suggest that we create an issue to track splitting this or simply follow up with a PR splitting this once it merges. @legendecas would you be okay with that approach?