Header list too large error gets changed to invalid content-type error

Hi!
We are seeing the following error message:
```
Caused by: io.grpc.StatusRuntimeException: INTERNAL: HTTP status code 431
invalid content-type: null
trailers: Metadata(:status=431,x-envoy-upstream-service-time=5,date=Wed, 08 Oct 2025 14:01:19 GMT,server=envoy)
at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:268)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:249)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:167)
```
The underlying issue here is that a header was too big and failed with:
```
431 INTERNAL ERROR header list size to send violates the maximum size (8192 bytes)
```
But the issue here is that the message:
`invalid content-type: null`
is misleading here and hides the original error, and causes confusion on what the error actually is. The issue seems to be that the client is expecting a `content-type: application/grpc` header to be present to parse the payload. But since the request failed when sending the headers, the response, which is an error response, doesn't have the `content-type` header set which causes the client to overwrite the original error.

Is this intended behavior or could the client handle this better? My guess here that this will be the case for any response where the headers are being validated as the request is prematurely interrupted.

I originally brought this up here https://github.com/envoyproxy/envoy/issues/41495 as the error included envoy. Envoy just forward this message to the client.

GRPC version is: 1.68.1

Start with the ClientCalls.java stack-trace entry point and trace how the gRPC client handles an HTTP 431 response without a content-type header. Reproduce the oversized-header response described in the issue, then verify that the original 431/header-list error remains visible instead of being replaced by “invalid content-type: null”.

Vom Indexierungsmodell aus dem Issue-Text verfasst.