This fixes a regression where `delayBody(N)` no longer makes a body look
slow to the caller. Read timeouts on the response stream are expected to
fire when N exceeds them, but in v14 the @mswjs/interceptors-based
pipeline drains the response body before delivering the response event.
Pausing the body source (the v13 mechanism) ended up delaying the
*whole* response — response, data, and end events all moved to
`+delayBodyInMs`, indistinguishable from a slow connection.

Two coordinated pieces fix it:

1. `lib/playback_interceptor.js`: drop the pause/resume mechanism and
   gate only the end-of-response push (`response.push(null)`) on
   `delayBodyInMs`. Schedule that gate inside `respond()` so
   `delay({ head, body })` continues to compound — head defers the
   response event, body then defers the end signal by an additional
   `body` ms. Reply callbacks like `replyWithFile` hand back an
   explicitly-paused `fs.createReadStream`, so call
   `bodyAsStream.resume()` to ensure the body flows.
2. `tests/got/test_delay.js`: the two tests that asserted timing on the
   first `data` event are updated to assert on the `end` event,
   matching the new (and intended) semantics.

Refs: #2867
Fixes: #2863