fix(ext/node): implement proper resourceLimits for node:worker_threads

[bartlomieju]

Summary

Implements proper resourceLimits support for node:worker_threads, matching Node.js behavior:

• Individual V8 ResourceConstraints: Uses set_max_old_generation_size_in_bytes, set_max_young_generation_size_in_bytes, set_code_range_size_in_bytes
• Stack size: Sets OS thread stack size via std::thread::Builder::stack_size() for stackSizeMb
• Resolved limits: Reads back V8 defaults for unspecified values via new op_worker_get_resource_limits op, so resourceLimits inside the worker always shows actual values (matching Node.js behavior)
• OOM handling: Installs near-heap-limit callback that terminates the worker with ERR_WORKER_OUT_OF_MEMORY error code
• Init ordering fix: Stores resolved limits in op_state before worker.bootstrap() so the polyfill can read them during init

Closes #26156
Closes #10036

[bartlomieju]

Needs denoland/rusty_v8#1918 to work

[kajukitli]

solid PR overall. few things:

1. near-heap-limit callback returns current_limit * 2 — this just delays the OOM. the callback will fire again and again until it eventually crashes. you probably want to just return current_limit or 0 to avoid extending the limit after triggering termination

2. division before storing resolved limits — params.max_young_generation_size_in_bytes() / mb does integer division. if v8 returns something not perfectly divisible by 1MB you're silently dropping precision. probably fine for practical purposes but worth a comment

3. resourceLimits: any = {} in typescript is a bit rough. you already have the type from WorkerOptions["resourceLimits"], could keep that

4. the test test-worker-resource-limits.js is skipped on all platforms — might be worth leaving a TODO for when v8.getHeapSpaceStatistics() lands

looks good otherwise, clean impl that matches node behavior

[bartlomieju]

1. near-heap-limit callback returns current_limit * 2 — this just delays the OOM. the callback will fire again and again until it eventually crashes. you probably want to just return current_limit or 0 to avoid extending the limit after triggering termination

This is fine - we're calling terminate_execution() there so JS will not execute anymore

4. the test test-worker-resource-limits.js is skipped on all platforms — might be worth leaving a TODO for when v8.getHeapSpaceStatistics() lands

It will be addressed in #32483.

[kajukitli]

Checked against Node source. A few behavioral differences:

1. Node always installs NearHeapLimitCallback for workers, regardless of whether resourceLimits is set (line 199 in node_worker.cc). This PR only installs it when has_resource_limits is true. Workers without explicit limits won't get graceful OOM handling in Deno.

2. Node has a minimum stack size check — if stackSizeMb * kMB < kStackBufferSize (192KB), it clamps to kStackBufferSize. This PR doesn't have that floor.

3. Node clamps maxOldGenerationSizeMb to minimum 2 in parseResourceLimits (lib/internal/worker.js line 632). This PR doesn't.

4. Node's resourceLimits getter on parent side calls getResourceLimits() on the handle to get live resolved values from V8. This PR just copies the input resourceLimits_ object on the parent side (only worker side gets resolved values via op).

5. NearHeapLimit return value — node returns current_heap_limit + 16MB, this PR returns current_limit * 2. Both work, just different.

Otherwise looks good, clean impl.

[devsnek]

fwiw this callback runs when v8 performs a last-resort gc. that gc might reclaim enough space that js is able to continue running normally.