test_runner: allow adapters to handle individual unhandled promise rejections

What is the problem this feature will solve?

(AI disclosure: text written by GPT-6 Astra Extra High, then read, tweaked, and signed-off on by @domenic.)

We are migrating jsdom's tests to node:test. Our Web Platform Tests adapter runs each WPT file inside a jsdom instance, waits for the embedded testharness.js harness to finish, and checks its results against our expectations.

Some WPTs deliberately produce unhandled rejections in iframe windows. These do not necessarily constitute failures of the parent window's test harness. Other rejections should become harness failures, which the adapter needs to evaluate against expected failures for unimplemented functionality.

Currently, node:test fails and aborts the enclosing test when it observes an unhandled rejection, before our adapter can finish evaluating the WPT. Adding our own process.on("unhandledRejection") listener does not prevent the test runner from independently failing the test.

We need a supported way for an embedded test harness to take responsibility for selected rejections, while preserving normal test-runner failure handling for unrelated rejections.

What is the feature you are proposing to solve the problem?

A per-test hook that can handle individual unhandled rejections before the test runner automatically fails or aborts the test.

For example, the API could look like this:

test("embedded harness", {
  onUnhandledRejection(reason, promise) {
    if (!adapter.ownsPromise(promise)) {
      return false;
    }

    adapter.recordUnhandledRejection(reason, promise);
    return true;
  }
}, async () => {
  await adapter.run();
  adapter.assertExpectedResults();
});

The important capabilities would be:

• The hook receives both the rejection reason and the actual promise, allowing the adapter to identify ownership.
• Returning true indicates that the adapter accepts responsibility for the rejection. The test runner does not automatically fail or abort the test for that rejection.
• Returning false or undefined preserves current behavior. Throwing from the hook fails the test.

What alternatives have you considered?

Stuff that doesn't work that we tried

• Adding a process-level unhandledRejection listener, including a prepended listener. The test runner still receives the event and fails the test.
• Using --unhandled-rejections=none. This suppresses warnings, but does not prevent the test runner from failing the test.
• Using expectFailure. This still lets the runner fail and abort the test instead of letting the embedded harness finish evaluating its results.

Stuff that works but is icky

• Wrapping process.emit to intercept selected rejection events. Small probes work on Node 22, 24, and 26 while preserving failure handling for unrelated rejections, but this requires monkeypatching and depends on the runner's reporting mechanism.
• Using node:domain. This can redirect rejections, but the API is deprecated and affects more than rejection reporting.
• Running the embedded harness in a separate process. This provides control over rejection handling, but adds process management and communication infrastructure.
• Skipping the affected tests. This avoids the immediate failures but loses regression coverage compared to mocha.

node:test runner の現在の未処理 rejection の処理から始め、jsdom WPT adapter のシナリオと、列挙されたプロセスレベルの代替案を再現コンテキストとして使用します。claimed、unclaimed、throwing、late の rejection を対象とするカバレッジを定義します。完了の条件は、焦点を絞ったテストによって、claimed rejection がそれを包含するテストを中断しない一方で、無関係な rejection は現在の動作を維持することを確認できることです。