src: wake worker drain for foreground tasks

[ghost]

Fixes #54918.

Wake a blocking worker drain when an immediate foreground task is posted, and flush foreground work while waiting for user-blocking worker tasks. A generation counter updated under the worker queue mutex prevents a wakeup delivered during foreground flushing from being lost before the next condition-variable wait.

Add a bounded cctest in which a user-blocking worker posts a foreground task and waits for it. Without the fix, the test reports the timeout instead of hanging indefinitely.

Validation:

• git apply --check --whitespace=error-all against the exact current/ blobs
• applied blob hashes match the reconstructed fixed files
• reverse application restores the exact supplied blobs
• apply/reverse-apply succeeds on an LF worktree and a CRLF worktree with core.autocrlf=true
• standalone 10,000-iteration synchronization harness
  (this is not a measured failure rate against the parent Node.js implementation)
• AddressSanitizer and UndefinedBehaviorSanitizer run
• Windows x64 A/B validation of PlatformTest.DrainTasksRunsForegroundTasksNeededByWorker using vcbuild.bat cctest openssl-no-asm vs2022 with clang-cl 19.1.5:
  • parent aed4eaf89dd8d47b9e399bccecc9a9fc588e0284, with the new regression test retained and only src/node_platform.cc and src/node_platform.h reverted: 0/20 passed, 20/20 failed (103.1 s total)
  • PR head 7a8597513e0682be6cb6d2f86b9f63610e1cd79e: 1000/1000 passed, 0/1000 failed (92.42 s total)

[avivkeller]

Validation of the rebased patch

Did you validate that your testing hardness fails 100% of the time in the previous Node.js version (e.g. if you ran a test script 10,000 times, would running that script several times result in a consistent failure rate (say 1 in 10,000, or something))?

[ghost]

Good question. I have not yet measured this against the actual parent Node.js revision.

The 10,000-iteration result in the PR description came from a standalone synchronization harness, not 10,000 runs of the Node.js cctest, so it should not be read as a measured Node.js failure rate.

The new cctest is intended to fail deterministically on the parent implementation, but that is currently a code-level expectation rather than an empirical A/B result. I’ll run the test unchanged against the parent revision, with only the new test applied, and against this PR head, then report the exact pass/fail counts and update the PR description.

Thanks for catching the ambiguity.

[ghost]

Thanks - the original "10,000-iteration" item referred to a standalone synchronization harness, not to a measured failure rate against the parent Node.js implementation. That wording was ambiguous.

I have now run an A/B validation using the actual Node.js cctest. I held the new regression test constant and reverted only src/node_platform.cc and src/node_platform.h for the parent run:

• parent aed4eaf89dd8d47b9e399bccecc9a9fc588e0284: 0/20 passed, 20/20 failed (103.1 s total)
• PR head 7a8597513e0682be6cb6d2f86b9f63610e1cd79e: 1000/1000 passed, 0/1000 failed (92.42 s total)

So the observed failure rate on the parent implementation was 100% in this 20-run sample, while the PR head had no failures in 1,000 runs.

I have updated the PR description to distinguish the standalone harness from this actual Node.js cctest A/B result.

[lpinca]

cc: @joyeecheung