fix: reassemble server-streaming google.api.HttpBody tool results instead of returning the last chunk

[hanxiaop]

Server-streaming tools return a summary result whose payload is the last message received, which is right for watch-style streams but wrong for google.api.HttpBody, where the stream is one document split into chunks. The generator now detects an RPC that streams HttpBody and emits a handler that stitches the chunks back together, in order, into a single tool result. The first chunk's content type picks the shape: image and audio become MCP media content, everything else must be valid UTF-8 and comes back as text, and a binary payload fails the call instead of returning mangled bytes. These tools advertise no output schema, and their progress events report cumulative bytes rather than a message count.

Reassembly is capped at 4 MiB by default so one call can't buffer unbounded data. The cap is tunable per server with protomcp.WithHTTPBodyDocumentLimit, and a document over the limit fails the call rather than being truncated. The greeter example adds a DownloadTranscript RPC with end-to-end tests covering the text, image, audio, binary-rejection, and size-limit paths.