[Java Client] HTTP errors during WebSocket handshake not surfaced as HttpRequestExceptions

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the bug

If an HTTP response for the opening SignalR negotiate call contains an unexpected response code, the SignalR Java client library will convert the error to an `HttpRequestException` for use by consumers of the library. However, if negotiation is skipped and a similar error occurs during the opening WebSocket handshake, the library does not return a useful exception. Instead, `OkHttpWebSocketWrapper.SignalRWebSocketListener.onFailure()` ignores the `Response` returned by OkHttp and wraps the provided `Throwable` in a `RuntimeException`.

This makes certain handleable errors, like 401, especially difficult to detect. I believe the only recourse today is to parse the error message string on the underlying `Throwable` returned by OkHttp.

### Expected Behavior

When negotiation is skipped, SignalR should return `HttpRequestException`s for the opening HTTP handshake in the WebSocket protocol, so we can handle the error codes (like 401) appropriately.

### Steps To Reproduce

1. Set up a basic SignalR Java client and SignalR service that supports authentication.
2. Configure the SignalR client to use WebSocket transport and skip negotiation.
3. Provide a bad token for the connection.

Expected: SignalR Java client receives an `HttpRequestException` with a 401 code.
Actual: SignalR Java client receives a generic `RuntimeException`.

### Exceptions (if any)

_No response_

### .NET Version

_No response_

### Anything else?

_No response_