Tighten gRPC response content-type validation

[fallintoplace]

Summary

• replace the gRPC unary response content-type prefix check with strict protocol-and-codec-aware validation
• allow the bare proto defaults (application/grpc and application/grpc-web) while still stripping parameters
• add regressions for rejecting gRPC-Web on a gRPC client, rejecting mismatched response codecs, and accepting application/grpc; charset=utf-8

Why

The previous starts_with("application/grpc") check accepted application/grpc-web* and never verified that the response codec matched the client configuration. That let a gRPC client accept gRPC-Web framing and could let a proto-configured client try to decode JSON bytes as proto.

Impact

• gRPC unary responses now require an exact allowed content type for the configured protocol and codec
• application/grpc remains accepted as the default proto subtype, even with parameters
• gRPC-family mismatches are rejected before body parsing starts

Validation

• cargo test -p connectrpc grpc_unary_
• cargo test -p connectrpc grpc_web_unary_stops_reading_after_trailer_frame

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}