perf: make the Node compile cache opt-in, persist worker caches on teardown - #10742

#10708 enabled Node's compile cache unconditionally. That turned out to be a bad default in two ways:

• On cold environments — CI that doesn't persist the cache directory — it makes runs slower: workers pay the code-cache production cost, and thread workers additionally serialize their whole compiled graph when they are terminated, with zero payoff since the directory is thrown away.
• For the default forks pool the cache was write-only anyway: SIGTERM'd workers never reach Node's exit-time flush, so worker entries (runtime, test environment, externalized deps) never reached the disk even when the directory did persist.

This PR makes the cache opt-in and makes opting in actually work:

• The executable no longer calls module.enableCompileCache(). Setting NODE_COMPILE_CACHE=<dir> enables the cache for the CLI (Node reads it at startup) and Vitest propagates it to every worker.
• Workers persist their compiled modules during graceful teardown (module.flushCompileCache() in the stop handler, both teardown paths; default import because a named import fails to link before Node 22.10). This is what makes the cache useful for forks.
• The v8 coverage provider still strips the cache from workers (V8 serializes cached scripts without the source positions precise coverage relies on) — now covered by a test.
• Documented in docs/guide/improving-performance.md as a tuning knob for environments where the directory survives between runs.

40-file happy-dom isolate: true suite, median of 5 interleaved runs (Apple M4 ×10, Node 24):

Cold runs get faster by default. Opting in pays the first-run serialization once and runs ~23% faster than that first run afterwards; the benefit over not enabling the cache at all grows with the size of the natively-imported graph (heavier environments and dependencies).

The e2e test covers env propagation into workers, NODE_DISABLE_COMPILE_CACHE precedence, and the coverage exclusion.