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.

Inizia dalla gestione attuale delle rejections non gestite del runner node:test, usando lo scenario dell’adattatore WPT di jsdom e le alternative a livello di processo elencate come contesto di riproduzione. Definisci la copertura per rejections dichiarate, non dichiarate, che generano errori e tardive; il lavoro è completo quando test mirati confermano che le rejections dichiarate non interrompono il test contenitore, mentre le rejections non correlate mantengono il comportamento attuale.