doc: note resourceLimits termination is best-effort

[jcross]

What the documentation says now

doc/api/worker_threads.md describes the resourceLimits option like this:

Reaching these limits leads to termination of the Worker instance.

The one caveat is for a global out-of-memory situation:

Even if these limits are set, the process may still abort if it encounters a
global out-of-memory situation.

What happens

A worker with maxOldGenerationSizeMb: 128 on a machine with free memory is not
in a global out-of-memory situation. It can still abort the whole process.

The result depends on the shape of the allocation, not on the total size. This
is Node.js v23.11.0 on Linux, with maxOldGenerationSizeMb: 128 in every run:

What the worker does	Result	Process
Many separate 10,000-element arrays	ERR_WORKER_OUT_OF_MEMORY on 'error', worker exit code 1	survives
Many separate 10,000-character strings	ERR_WORKER_OUT_OF_MEMORY on 'error', worker exit code 1	survives
One new Array(1e8), then filled by index	FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed	aborts, exit 134
push() 1e8 times onto one array	FATAL ERROR: Reached heap limit Allocation failed	aborts, exit 134

The first two rows are the documented behavior. The last two are not.

The fourth row is the reason for this pull request. push() in a loop looks
like many small allocations, but the backing store doubles, so one growth step
becomes a single large allocation. Ordinary code reaches the fatal path.

Repro for the fourth row, with no dependencies:

const { Worker, isMainThread } = require('node:worker_threads');
if (isMainThread) {
  const w = new Worker(__filename, { resourceLimits: { maxOldGenerationSizeMb: 128 } });
  w.on('error', (e) => console.log('error event:', e.code));
  w.on('exit', (c) => console.log('worker exit:', c, 'main alive:', Buffer.alloc(1e6).length === 1e6));
} else {
  const a = [];
  for (let i = 0; i < 1e8; i++) a.push(false);
}

The process aborts. Neither handler runs.

Why the existing caveat does not cover this

The caveat names a global out-of-memory situation. The host has memory to spare
here. What is reached is the limit that resourceLimits sets, which is the case
the sentence above the caveat says is contained.

This is known and it is not a defect report

#47224 reports this behavior and
was closed as inactionable, because out-of-memory errors are not recoverable and
this is a V8 limitation. That closure is not in question here, and this pull
request asks for no change in behavior.

The reason to change the documentation is in that same thread:

Node does try to terminate workers when it detects almost-out-of-memory
conditions but that's a best effort attempt, it's not 100% reliable.

That is an accurate description, and the documentation does not contain it. This
pull request copies it into the page.

#64155 is an open report of the
same class on v26.4.0, through a large inline source map, so the behavior is
current.

A note on the second hunk

ERR_WORKER_OUT_OF_MEMORY was not referenced anywhere in worker_threads.md
before this change, so the link definition had to be added. Without it
lint-md fails with no-undefined-references.

How this was tested

The four rows above were measured, each in a separate process, reading the exit
code directly rather than through a pipe.

node tools/lint-md/lint-md.mjs doc/api/worker_threads.md exits 0 on this
branch. I also checked that the linter catches the missing link definition, by
removing it and confirming the no-undefined-references warning, so the pass is
a real result and not an unrun check.

Please correct the wording as you prefer. You know how much detail belongs in an
option description better than I do, and a shorter version that keeps
"best-effort" would still fix the part that is wrong.