Fixture recording and replay throw on 204, 205, and 304 responses

I found that both fixture replay and recording throw on valid no-content HTTP responses. This prevents testing or recording calls such as a successful DELETE returning 204, before the connector can inspect the status.

Save the following as repro-no-content.ts at the repository root and run deno run --allow-read --allow-env repro-no-content.ts with Deno 2. It uses a local stub and needs no network or credentials:

import {recordingFetch,replayFetch,type RecordedCall} from './shared/testing/fixtures.ts';
for(const status of [204,205,304]) {
 const sink:RecordedCall[]=[];
 try {await recordingFetch(()=>Promise.resolve(new Response(null,{status})),sink)('https://api.test/item',{method:'DELETE'}); console.log('record',status,'OK');}catch(e){console.log('record',status,String(e));}
 try {await replayFetch({name:'empty',description:'empty response',calls:[{req:{method:'DELETE',url:'https://api.test/item'},res:{status,body:null}}]})('https://api.test/item',{method:'DELETE'});console.log('replay',status,'OK');}catch(e){console.log('replay',status,String(e));}
}

All six cases print TypeError: Response with null body status cannot have body. I expect recording and replay to return a Response with the original status and an absent body.

replayFetch always passes JSON.stringify(call.res.body) to the Response constructor: even a fixture's body: null becomes the nonempty string "null". recordingFetch reads an empty response as "" and passes that string into a new Response. Both violate the no-body requirement for 204, 205, and 304.

I propose passing a null body when reconstructing these three statuses, preserving the status and existing allowlisted headers. Regression tests should cover each status in replay, record→replay, null/empty fixture representations, and a 200 JSON-null payload as a positive control.

I searched open and closed issues/PRs for replayFetch, recordingFetch, 204, and null-body responses and found no matching fix. This is confined to fixture reconstruction and does not add the binary/multipart transport support discussed in #170.