[Problem/Bug]: Correct processing of HTTP error codes for XMLHttpRequest

What happened?

It is impossible to obtain information about HTTP errors (401, 403 and some other) when something goes wrong and the "error" listener of the XMLHttpRequest is triggering. It affects different frameworks like axios. For example: https://github.com/axios/axios/issues/4420#issuecomment-1066104366

Importance

Moderate. My app's user experience is affected, but still usable.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

130.0.2849.56

SDK Version

1.0.2420.47

Framework

Other

Operating System

Windows 11

OS Version

22631.4317

Repro steps

1. Open WebView's developer's console
2. Add the script
   x = new XMLHttpRequest();
   x.addEventListener("error", (e) => {
   console.log(e);
   });
   x.open("POST", "<any URL which triggers HTTP 401 or 403");
   x.send()

Expected result: The error listener will not be triggered at all (because these are application-level errors) or the "e" parameter of the function will contain some information about an exact HTTP status.

Actual result: The "e" parameter of the function has no information about an exact HTTP status which makes it impossible to differ application-level problems (HTTP codes) from network problems.

Additionally: Correct information is shown in console output at the same time: "POST net::ERR_FAILED 401 (Unauthorized)" so the code should be available for adding to the error.

Repros in Edge Browser

Yes, issue can be reproduced in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

Start by running the XMLHttpRequest repro in the listed WebView2 stable runtime and compare it with the corresponding Edge version. Investigate how HTTP 401/403 responses are surfaced when the error listener fires, using the console's ERR_FAILED status as the reference. Done means the behavior is documented or corrected so application-level HTTP errors can be distinguished from network failures.