sendMaxBytes incorrectly applied to EndStream control frames in streaming RPCs

[washanhanzi]

Bug

envelopeWriter.Write() applies sendMaxBytes to all envelopes, including EndStream control frames. When a streaming message exceeds sendMaxBytes, the handler correctly gets CodeResourceExhausted from stream.Send(). But when connect-go tries to write the error into an EndStream frame via MarshalEndStream, the serialized error JSON itself may also exceed sendMaxBytes, causing the EndStream to be silently dropped. The client receives an empty HTTP 200 response with no error information.

Code path

1. stream.Send() → envelopeWriter.Write() rejects the oversized message:

   if w.sendMaxBytes > 0 && env.Data.Len() > w.sendMaxBytes {
       return errorf(CodeResourceExhausted, "message size %d exceeds sendMaxBytes %d", ...)
   }

2. Handler returns the error → connCloser.Close(err)

3. connectStreamingHandlerConn.Close() calls MarshalEndStream(err, ...) — if this fails, the error is swallowed

4. MarshalEndStream() passes the EndStream envelope through the same envelopeWriter.Write():

   return m.Write(&envelope{Data: raw, Flags: connectFlagEnvelopeEndStream})

5. envelopeWriter.Write() checks sendMaxBytes again — the error JSON is typically larger than the limit → EndStream frame is never sent.

connect-es does not have this issue

In connect-es, endStreamSerialization is created separately and is not wrapped with limitSerialization:

• Message serialization: limitSerialization(createBinarySerialization(...)) — applies writeMaxBytes
• EndStream serialization: createEndStreamSerialization() — no size limit applied