fix: do not call onResponse when no response was received

[L-Blondy]

Fixes #88

Problem

onResponse is typed (response: Response, request: Request) but was invoked with undefined when fetchFn rejected (e.g. ECONNREFUSED), via an unsound non-null assertion in up.ts. A hook trusting the type then threw a TypeError that masked the original network error.

Repro (before this fix):

const upfetch = up(fetch)
await upfetch('http://localhost:59999/nope', {
   onResponse(response) {
      // response is undefined here, despite being typed as Response
   },
})
// throws ECONNREFUSED

Fix

Throw the stored error before invoking onResponse:

if (error) throw error
await defaultOpts.onResponse?.(response!, request)
await fetcherOpts.onResponse?.(response!, request)

• After the retry loop, error === undefined implies a response was received, so the remaining response! assertions become sound.
• onResponse now fires iff the request concluded with a response; it still runs before onError for rejected (non-2xx) responses.
• This also covers the retry edge case where an earlier attempt received a response but the final attempt failed with a network error: onResponse no longer fires with the stale response, and a throwing hook can no longer mask the original error.
• The network-failure path is already covered by onError (and the error is still thrown), so no information is lost.

This was chosen over widening the type to Response | undefined, which would be a breaking change forcing every consumer to handle undefined.

Also updates the onResponse doc comments and README tables to clarify that it only runs when a response is received.

Testing

• Regression test: a request to a port with no listener (real ECONNREFUSED) must not trigger onResponse (default or fetcher-level), and the call still rejects.
• Regression test: attempt 1 returns a 500, the retry fails with a network error — onResponse must not fire with the stale first response.
• Full suite passes: 160 tests, biome check, and tsc --noEmit.