Fixes #5431

Problem

The third case in parseResponse > should throw error matching snapshots
checks that when fetch itself rejects, parseResponse passes the original
error through unwrapped. It produced that rejection by requesting
http://localhost/noRoute, which has no MSW handler, so the request escaped
to the real network and relied on nothing listening on port 80.

On machines where something does listen on port 80 (in my case IIS 10.0 on
Windows), that request receives a 404 instead, and the test fails with:

• Expected: [TypeError: fetch failed]
• Received: [DetailedError: 404 Not Found]

Fix

Add an explicit MSW handler for that route that returns
HttpResponse.error(), so fetch rejects deterministically without the
request ever reaching the network. The comment above the case is updated to
explain this.

The snapshot message changes from fetch failed (Node's fetch, on a real
connection failure) to Failed to fetch (MSW's simulated network error).
It is still a TypeError thrown at the fetch call, which is what this
case verifies.

Verification

On Windows 11, with vitest 5.0.1 and msw 2.15.0 installed from the lockfile:

• With IIS running on port 80: all 32 tests in src/client/utils.test.ts pass
• With IIS stopped: all 32 tests pass
• The MSW "intercepted a request without a matching request handler" warning
  no longer appears in either run

Before this change, the same file failed with IIS running and passed with
it stopped.

The author should do the following, if applicable

• Add tests
• Run tests
• pnpm run format:fix && pnpm run lint:fix to format the code
• Add TSDoc/JSDoc to document the code (not applicable, test-only change)