Incorrect HTTP/3 error code for malformed requests with invalid pseudo-header

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Describe the bug

According to the [RFC 9114 HTTP/3](https://www.rfc-editor.org/rfc/rfc9114.html), We need to recognise a malformed request based on the criteria outlined in [section-4.1.2](https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1.2) of the RFC:

> A malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to:
>- the presence of prohibited fields or pseudo-header fields,
>- the absence of mandatory pseudo-header fields,
>- invalid values for pseudo-header fields,
>- ...

Additionally, based on [section-4.1.2-4](https://www.rfc-editor.org/rfc/rfc9114.html#section-4.1.2-4) in the HTTP/3 RFC, we should handle malformed requests by sending an `H3_MESSAGE_ERROR` HTTP error code.

> Malformed requests or responses that are detected MUST be treated as a [stream error](https://www.rfc-editor.org/rfc/rfc9114.html#errors) of type [H3_MESSAGE_ERROR](https://www.rfc-editor.org/rfc/rfc9114.html#H3_MESSAGE_ERROR).

**I've found a few instances where we're treating these cases as `H3_GENERAL_PROTOCOL_ERROR`, which isn't quite right.**

One example is when there are **invalid values for pseudo-header fields**. For instance, if we receive an invalid `:authority` pseudo-header like `userinfo@abs.dfe` which includes a subdomain(violate [section-4.3.1-2.10.1](https://www.rfc-editor.org/rfc/rfc9114.html#section-4.3.1-2.10.1)), we should respond with an `H3_MESSAGE_ERROR`. However, in the current implementation of Kestrel's HTTP/3, it returns a `H3_GENERAL_PROTOCOL_ERROR` instead in this [line](https://github.com/dotnet/aspnetcore/blob/1b454f57c664c1d43348c6c74cde7a2119813c8a/src/Servers/Kestrel/Core/src/Internal/Http3/Http3Stream.cs#L1114).

### Expected Behavior

_No response_

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### .NET Version

_No response_

### Anything else?

_No response_