Include original response in client errors

[adambrgmn]

This PR adds the original fetch response to client errors to be able to act on non-graphql responses returned by the api.

The reason we need this is because we integrate with an api that might at any time return a non-graphql response in case of an error. And the body returned might hold reasons for the error which can't be parsed by the graphql parser.

We have tested this as a local patch for a while and think it is very useful, hence this PR.

This is connected to issue #1473.

[jasonkuhrt]

Thanks for the PR @adambrgmn! I've pushed a refactored approach that I think better addresses your use case.

Changes Made

Instead of exposing the full Response object (whose body stream is already consumed by the time you receive the error), I've exposed the useful data directly on GraphQLResponse:

interface GraphQLResponse<T = unknown> {
  // ... existing fields
  headers: Headers    // ✅ Access response headers (e.g., Kill-Switch)
  body: string        // ✅ The response body text for non-GraphQL responses
}

Why This Approach?

1. No consumed-stream footgun: The original Response object's body can only be read once. Since runRequest already calls response.text() to parse the body, originalResponse.text() would return an empty string - a confusing gotcha.

2. Direct access: You can access headers and body directly without needing the Response wrapper:

   if (error instanceof ClientError) {
     const hasKillSwitch = error.response.headers.get('Kill-Switch')
     if (hasKillSwitch) {
       const reason = JSON.parse(error.response.body)
       throw new KillSwitchError(reason)
     }
   }

3. No breaking changes to ClientError constructor: The constructor signature stays the same.

Test Added

I added a test case that validates the exact use case from your issue - accessing custom headers and parsing non-GraphQL response bodies.

---

Does this approach work for your use case? If you need anything else from the Response object that I missed, let me know!

[adambrgmn]

That improvement is great. My solution was very basic. I did res.clone().json() in my approach since it was already read. But I'm sure this is more efficient and it will suit our use-case well 👍