fix: parse GraphQL errors from response body on HTTP 4xx/5xx status codes

[jasonkuhrt]

Summary

Fixes regression from v6 to v7 where HTTP 4xx/5xx responses would throw ClientError without including the GraphQL errors from the response body.

Changes

• Parse response body before checking HTTP status in runRequest.ts:74-102
• Include parsed GraphQL response (errors + data) in ClientError when HTTP status is non-2xx
• Add comprehensive test suite covering various HTTP error status codes (422, 500, 404, 403, 400)

Rationale

In v6, when a server returned a 4xx/5xx HTTP status with a valid GraphQL response body containing errors, users could access those errors via error.response.errors. This was a common pattern for handling authentication errors (422), server errors (500), etc.

The v7 implementation in runRequest.ts checked fetchResponse.ok before parsing the response body, which meant the GraphQL errors were never extracted and included in the ClientError. This broke user code that relied on accessing error details.

Solution

The fix moves the parseResultFromResponse() call to happen before the HTTP status check. This ensures:

1. Response body is always parsed if it contains valid GraphQL response
2. ClientError includes both HTTP metadata (status, headers) AND GraphQL response data (errors, data)
3. Behavior matches v6 where errors are accessible regardless of HTTP status

Test Plan

• ✅ All existing tests pass (75 tests)
• ✅ New test suite with 5 test cases covering:
  • 422 status with GraphQL errors + data
  • 500 status with GraphQL errors only
  • 404 status with GraphQL errors
  • 403 status with partial data + errors
  • 400 status with validation errors

Closes #1281