[v22.x backport] test_runner: convert to uint during deserialization

[positivef]

Backport of #64706 to v22.x-staging. Backport was requested in #65934.

What is included

Only the lib/internal/test_runner/runner.js hunk. It cherry-picks cleanly onto v22.x-staging (offset -135 lines) and the diff here is identical to the original hunk.

What is NOT included, and why

The original commit also added a case to test/parallel/test-runner-v8-deserializer.mjs:

it('should read an oversized length as an unsigned integer', async () => {
  const reported = await collectReported([unsignedOversizedLengthHeader]);
  ...
});

That test would hang on v22.x. It depends on #62704 (debe2ed2efd3, "test_runner: avoid hanging on incomplete v8 frames"), which is not on this line. On v22.x, #drainRawBuffer is still:

#drainRawBuffer() {
  while (this.#rawBuffer.length > 0) {
    this.#processRawBuffer();
  }
}

so a frame whose declared length exceeds the buffered bytes is never consumed and the loop never ends. Measured on v22.19.0 against the shipped FileTest (--expose-internals, feed one chunk to parseMessage, then drain()):

chunk	v22.19.0 today
ff 0f 7f ff ff ff (oversized, positive)	hangs — killed after 12 s
ff 0f 00 01 00 00 (truncated)	hangs — killed after 12 s
ff 0f 80 00 00 00 (the case this fix is about)	throws Unable to deserialize cloned data …

With >>> 0 applied, the third row joins the first two, so importing the upstream test as-is would wedge the suite on this line.

For the same reason #62704 is not a trivial follow-up: it does not apply cleanly to v22.x-staging — both runner.js and the test file conflict. I am happy to prepare that backport as a separate PR if you would rather the test came along with the fix; please tell me which ordering you prefer.

Why the fix is still worth having on v22.x without its test

The real-world trigger is not synthetic. #processRawBuffer advances bufferHead past a consumed message and then reads the next four bytes as a length without re-checking for the ff 0f header, so any non-ASCII byte a test writes to stdout immediately after a report message is read as the top byte of that length. Every UTF-8 lead/continuation byte is >= 0x80, which makes fullMessageSize negative and defeats the if (this.#rawBufferSize < fullMessageSize) break guard.

Unlike the synthetic case in the table, that path is genuinely repaired by >>> 0 on this line: the oversized length now makes the loop break, and because those bytes do not start with ff 0f they are subsequently emitted through the non-serialized stdout path instead of being handed to DefaultDeserializer.

A deterministic reproduction (no load, no concurrency — one write(), and an env var flips it between failing and passing) and the three symptoms observed on v22.19.0 — including one where a whole test file's results disappear with no failure, no summary and no error text — are in #65934.

Checklist

• Maturity: landed on main 2026-07-26 and shipped in v26.7.0 on 2026-08-05, so it has been in Current well beyond the two-week requirement for LTS lines.
• make -j4 test: not run. I have no Node build environment on this machine, so I have only verified that the hunk applies cleanly and matches the original. Please treat CI as the source of truth.
• Per the backporting guide the commit message is left exactly as it landed on main, and no Backport-PR-URL entry was added by hand.

[nodejs-github-bot]

Review requested:

• @nodejs/test_runner

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.