Fix Fetch response metadata in HTTP errors and transfer cache - #69531

We can't land a feat commit in a patch version. Wdyt of making the change a refactor ?

Which use-cases / issues are we fixing with these changes?

@alan-agius4
Currently, the first commit[fix(http): handle missing redirected and responseType in HttpErrorResponse] fixes the fact that we never receive redirected and responseType when the request fails for some reason or due to server rejection; currently, it comes as undefined, which doesn't help the user know if they were redirected or what the responseType is.

The second fix addresses the issue of the new properties not being properly tested because TestRequest.flush() and TestRequest.error() are not passing the redirected and responseType properties. Additionally, the same problem would occur in the TransferCache; a user making a request from the server side would likely expect or assume that these properties would be available.

Thanks for working on this!

After reviewing the changes and the use cases:

1. For non-2xx responses, FetchBackend already populates redirected and responseType on HttpErrorResponse (and in the await fetchPromise catch block, response is always undefined).
2. Persisting redirected and responseType in TransferCache increases the serialized TransferState HTML payload for every SSR request when using withFetch() (where redirected and type are always defined), and the server-side Response.type (e.g., basic vs. cors from the Node.js server's perspective) does not necessarily reflect what a browser client request would produce.

Since there isn't a compelling use case that justifies the additional transfer state payload and complexity, I'm going to close this PR. Thanks again for your contribution!