client: tighten gRPC and gRPC-Web unary response parsing

[iainmcgin]

Two follow-ups from the recent client-streaming response parser work (#133), where the same shape exists in milder form:

• parse_grpc_unary_response decompresses every data envelope it encounters and only enforces the single-message expectation afterwards (later envelopes overwrite earlier ones rather than accumulating). Rejecting a second data envelope before decompressing it would match the Connect client-streaming behaviour.
• The gRPC-Web response collection loop buffers frames until body EOF or the size cap and only then looks for the trailers frame (flag 0x80). Stopping at the trailers frame would avoid buffering and then failing on data a server sends after it, and would let well-formed responses complete even if the server keeps writing.

Both are bounded today by the existing response-buffer caps; this is about failing fast and doing no more decompression work than the RPC shape allows.