Guard worker fetch relay against null-body-status Response throw

[ryanbr]

Problem

The worker fetch relay reconstructs the worker's fetch responses on the worker side:

const response = new Response(responseData.body, { status: responseData.status, … });

new Response(body, { status }) throws a RangeError when a non-null body is paired with a null-body status (101 / 204 / 205 / 304). The main-thread relay supplies the body as await response.text() — which is an empty string '' (not null) for those statuses. So a 304 Not Modified or 204 returned through the relay (e.g. a conditional playlist/token request) makes the worker-side reconstruction throw: the relayed fetch never resolves, and the worker hangs on it until the relay timeout fires.

Fix

Drop the body for null-body statuses before constructing the Response:

const _nullBodyStatus = responseData.status === 101 || responseData.status === 204 || responseData.status === 205 || responseData.status === 304;
const response = new Response(_nullBodyStatus ? null : responseData.body, { status: responseData.status, … });

Status/statusText/headers are unchanged, as is the url/redirected/type post-assignment the IVS WASM validation needs.

Scope

• Real-but-low-frequency: most relay fetches are 200; 304 is the realistic trigger. The relay timeout already bounds the hang, so this is a robustness fix, not a crash.
• Mirrors GosuDRM/TTV-AB v9.7.1 ("responses with status 101, 204, 205, or 304 are now rebuilt without a body") and v9.9.0 ("exhausted token fetches return a real network-error response instead of throwing from the Response constructor") — shared relay lineage, upstream hit it in the field.
• vaft release pair; mirrored to the testing pair (direct to master, v658). npx acorn clean on all four files. No version bump (accumulates under ## Unreleased).

🤖 Generated with Claude Code