client: validate streaming gRPC response content types

[EffortlessSteven]

What this does

Server-streaming and bidi receive initialization did not validate that a successful response's content-type matched the configured gRPC family or codec. In the trailers-only regression, a gRPC client accepted application/grpc-web+proto: call_server_stream returned Ok(ServerStream), then message() returned Ok(None).

make_server_stream now reuses the unary validator after response-status classification and before encoding or stream construction. Missing and bare-family content types remain accepted; Connect and non-200 HTTP precedence are unchanged.

Fixes #203.

Verification

Check	Result
public trailers-only witness	unpatched Ok(ServerStream) then Ok(None); patched Unknown before stream exposure
ordinary response heads	family and codec mismatches rejected without grpc-status; headers and compatibility cases preserved
mutation proof	six mutants killed: deleted or conditional validation, hard-coded selectors, wrong ordering, and wrong call site
#1123 runner	1,462 gRPC and 2,854 gRPC-Web cases passed with zero failures

Review map

• validate_grpc_response_content_type: takes protocol and codec directly.
• make_server_stream: shared server-streaming and bidi validation seam.
• Tests and changelog: rejection and compatibility tests, HTTP 502 precedence, and the public false-success regression.

[iainmcgin]

[claude code] Thanks for this — the fix is well-placed and the tests are thorough. To get it into 0.9.0 I've rebased the branch onto current main (which now has #257, #262, #236 and #238, all of which touch make_server_stream or the validator's call sites) and pushed one maintainer commit on top rather than round-tripping review comments. Your commit is unchanged apart from the rebase.

The fixup addresses one behavioural question the review turned up. With the validation placed after the trailers-only check, a trailers-only reply carrying a wrong-family content-type and a non-zero grpc-status was believed for its status on the streaming path but rejected as unknown on the unary path (which, since #257, settles HTTP status and content-type before reading grpc-status, as connect-go's grpcValidateResponse does). Same bytes, two answers. Rather than document the divergence, the unary gate is now extracted as check_grpc_response_head and make_server_stream calls it before parse_grpc_error_from_trailers, so the two paths agree by construction. A side effect is that a non-2xx reply that isn't speaking gRPC now carries the content-type detail after HTTP error N on streaming calls too, matching unary.

Also in the fixup: a parity test that drives the same response head through both parsers across the status / content-type / grpc-status matrix; two extra accept-side rows (application/grpc+json exact match, and Connect streaming being unaffected); and a correction to the pre-existing test comment that said the bare type is accepted for every codec "as in connect-go" (connect-go only accepts it for proto — your rewritten function doc already had this right). Changelog fragment extended by a sentence.

Verified locally on the rebased branch: 635 unit tests, client conformance gRPC 1454/0 and gRPC-Web 2838/0.

Connect-protocol streaming responses remain unvalidated here (connect-go does check them); the failure mode is a clean internal at end-of-stream rather than a silent Ok(None), so I'll file that as a follow-up rather than widen this PR.