src,test: fix and test Environments sharing an isolate

[codebytere]

Refs: #65977

Node.js supports running several Environments on one isolate and event loop, including an isolate the embedder created itself, but no test builds that setup. The crashes fixed in it over the past month were all found by embedders.

This adds a cctest that does: it creates the isolate, CppHeap and contexts the way an embedder would, starts a few Environments that keep timers running, and then frees, stops and inspects them one at a time while checking that the others keep working. It runs once with a shared IsolateData and once with one per Environment. Reverting any of the recent fixes makes it fail.

Writing it turned up three small issues, fixed in separate commits:

• The src: fix FreeEnvironment() breaking JS in sibling Environments #65977 fix didn't cover Environments with their own IsolateData; its counter is now per thread.
• An Environment without an inspector threw a plain string from node:inspector; it now throws ERR_INSPECTOR_NOT_AVAILABLE.
• Freeing an IsolateData before its Environments now fails a CHECK instead of leaving a dangling pointer.

It also rewrites the multiple-Environments section of embedding.md to describe the supported setup.

---

Disclosure: the code, tests, docs and this description were written by Claude Code, directed and reviewed by @codebytere.

[nodejs-github-bot]

Review requested:

• @nodejs/inspector

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.31%. Comparing base (6dfe4eb) to head (df2ae81).
⚠️ Report is 74 commits behind head on main.

Files with missing lines	Patch %	Lines
src/env.cc	85.71%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #66239      +/-   ##
==========================================
+ Coverage   90.28%   90.31%   +0.02%     
==========================================
  Files         789      789              
  Lines      272878   272880       +2     
  Branches    52109    52104       -5     
==========================================
+ Hits       246363   246442      +79     
+ Misses      16979    16903      -76     
+ Partials     9536     9535       -1     

Files with missing lines	Coverage Δ
src/api/callback.cc	83.25% <100.00%> (+0.47%)	⬆️
src/env.h	97.33% <100.00%> (+0.07%)	⬆️
src/inspector_agent.cc	83.20% <100.00%> (+1.46%)	⬆️
src/node_internals.h	80.35% <ø> (ø)
src/env.cc	82.16% <85.71%> (+0.04%)	⬆️

... and 30 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[joyeecheung]

hmm, I am not quite sure if this is something we are ready to support, IIRC we have a some places that simply assume "on thread, one isolate, one Environment" so making "multiple Environments sharing the same isolate" means these code now have to use something more sophisticated than thread_locals to retrieve states that are really per-Environment. I think some mechanism needs to be provided to organize these better before we can officially call it supported?

[codebytere]

@joyeecheung fair - i went through the thread_locals in src/ and it looks like two of them hold per-Environment state:

• the root cert store in crypto_context.cc: tls.setDefaultCACertificates() in one Environment changes it for the others
• quic_alloc_state in quic/bindingdata.cc: binding points at the last BindingData created on the thread, so one Environment's QUIC session frees against another's counter

The rest are re-entrancy guards and debug counters that are fine per thread.

Would something like this cover it?

• a typed slot for native state on Environment (e.g. env->GetOrCreateNativeState<T>()), destroyed in FreeEnvironment()
• callbacks reach it through their user_data or Environment::GetCurrent(isolate) instead of a thread_local
• a lint that rejects new thread_locals in src/ unless they're marked as intentionally per-thread

i'll drop the docs commit so this PR doesn't call the setup supported, and can open the slot as its own PR first?

[legendecas]

btw the PR title looks like this is a test only change.

[nodejs-github-bot]

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