Reject malformed Connect END_STREAM JSON

[fallintoplace]

Summary

• Reject malformed Connect END_STREAM JSON as an internal protocol error instead of treating it as an empty successful terminator.
• Share END_STREAM parsing, trailer conversion, and error conversion between the server-stream and client-stream response paths.
• Add regression coverage for malformed END_STREAM JSON in both paths.

Why

The client used serde_json::from_slice(...).unwrap_or_default() when parsing Connect END_STREAM payloads. Invalid JSON therefore became the default successful end-stream shape, so a malformed protocol terminator could be reported as a clean RPC completion.

Testing

• cargo test -p connectrpc malformed_end_stream_json
• cargo test -p connectrpc
• cargo test --workspace
• cargo check -p connectrpc --no-default-features
• cargo clippy -p connectrpc --all-targets --all-features -- -D warnings
• git diff --check

[github-actions]

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

[fallintoplace]

I have read the CLA Document and I hereby sign the CLA

[iainmcgin]

[claude code] Thanks — the fix is correct and the regression tests are well-targeted. I pushed one maintainer commit (d55d2da) that merges main and resolves the conflict in client/mod.rs:

• Dropped metadata_to_trailers and kept main's append_metadata_capped at both call sites. The extracted helper carried the pre-#169 uncapped HeaderMap::append loop, which panics at the map's ~32k-entry ceiling — a server can hit that with a few hundred KB of END_STREAM JSON. #169 replaced both sites with try_append-and-stop; the resolution preserves that guard while keeping your parse_connect_end_stream / end_stream_error_to_connect_error extractions.
• Removed the Default derive on ClientEndStreamResponse — it existed only for the unwrap_or_default() this PR removes, and leaving it would let a future .unwrap_or_default() compile and silently reintroduce the bug.
• Added a CHANGELOG.md entry under [Unreleased] / Fixed alongside its #163/#168 siblings, plus doc comments on the two new helpers.

One pre-existing asymmetry surfaced during review (not a regression here, so not addressed in this PR): the server-stream parse-error path at process_end_stream doesn't attach self.headers to the returned ConnectError, while the client-stream path does. Worth a follow-up to make them uniform.

LGTM with the above applied.