Treat response deserialization failures as request errors

[ejsmith]

Summary

• preserve the original abort reason when a signal cancels a successful response body read
• throw a new exported FetchClientDeserializationError when a successful response body cannot be read or parsed as JSON
• keep malformed non-success responses on the existing RFC 7807/status-error path
• run deserialization failures through middleware and errorCallback, avoid caching them, and always clear request loading counters
• document the behavior change and add regressions for abort-during-body-read and malformed 2xx JSON

Root cause

getJSONResponse caught body-read and JSON parsing failures and assigned a generated ProblemDetails instance to response.data. Because the original HTTP response could still have ok === true, callers and query libraries treated that problem object as successful typed data.

Behavior change

Successful responses with invalid JSON now reject with FetchClientDeserializationError. The error exposes the underlying FetchClientResponse, parsing/reading cause, and responseText. Caller cancellation is not wrapped: the request rejects with the signal's original abort reason. shouldThrowOnUnexpectedStatusCodes remains limited to HTTP status handling. An errorCallback can still explicitly suppress a deserialization error by returning true, in which case data is null rather than ProblemDetails.

Actual non-success HTTP responses continue to populate response.problem and use existing status handling.

Validation

• deno task format-check
• deno task lint
• deno task check
• deno task test — 200 passed
• deno task build --set-version 0.0.0 --allow-dirty
• verified the generated package exports FetchClientDeserializationError
• git diff --check

Closes #31