src: do not use --allow-overwriting-for-next-flag

[ShogunPanda]

Summary

Replace the V8 flag overrides introduced in #66459 with explicit rejection of unsupported modes. This removes the dependency on --allow-overwriting-for-next-flag, which newer V8 versions have removed, as an alternative to the revert proposed in #66516.

Changes

• Reject --jitless and --lite-mode, including alternate spellings, before passing them to V8.
• Report invalid CLI options with exit code 9.
• Throw ERR_INVALID_ARG_VALUE from v8.setFlagsFromString() without applying any flags from the rejected call.
• Use the diagnostic Node.js does not support V8 flag <flag>..
• Update documentation and coverage for rejection, worker behavior, and continued WebAssembly availability after catching the error.

Notes

This preserves the removal of jitless support rather than restoring an opt-in. That behavior remains subject to agreement with reviewers.

Assisted-By: OpenAI:GPT-6.1 Sol <openai/gpt-6.1-sol>

Supersedes #66516.

[nodejs-github-bot]

Review requested:

• @nodejs/startup

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78175/

[aduh95]

Why this change?

[ShogunPanda]

Because it's not strictly bound to WASM. Even FFI Fast API requires RX memory.

[ShogunPanda]

@aduh95 I totally reworded all message not to mention WASM. PTAL.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78176/

[joyeecheung]

To follow up #66459 (comment) here:

2 - we let them to, but whenever the user tries to access WebAssemly we also throw an error and exit. But this also means that some part of Node might be totally unaccessible in the future.

I think this is a better outcome, or we can go a bit more friendly and throw when an API that requires WASM to function is loaded, similar to how we throw for crypto in no-openssl builds, that way users can get a more informative message and know what's going on. We could also introduce an error code for the unsupported feature for users to detect and fall back gracefully, say from the perspective of a library, if the built-in fetch is available, use that, otherwise use a custom one that doesn't need WASM to work, maybe at the expense of performance, but at least it stays functional. People do use --jitless on platforms where JIT is generally not available due to permission issues. We shouldn't assume that just because some built-in Node.js features are not available, people would be completely out of alternatives, especially in the case of fetch and TypeScript, when there are plenty of user land alternatives that work well under jitless mode.

[ShogunPanda]

We already have ERR_WEBASSEMBLY_NOT_SUPPORTED for that.

I can live with that, but I also will explicitly document that we don't support or try to fallback feature when WASM o RX memory is lacking.

If you're fine with that I will send a PR.

[ShogunPanda]

Obsoleted by #66516.

[ShogunPanda]

@joyeecheung I've created #66533 which implements #2.