fetch: cap the response body size while reading, instead of buffering it whole #5370

Problem

mcp-server-fetch reads the whole response body into memory before it converts or truncates anything (response.content / response.text in server.py). max_length only limits what is returned to the client, after the full body has been downloaded and decoded. A URL that serves a very large or endless body therefore makes the server buffer all of it, which can exhaust memory and take the server down.

The private-address guard shipped in #5033 covered the network-destination half of #4116 / #3741; the oversized-response half was never addressed.

Expected behavior

The server stops reading once the body passes a fixed byte cap (a streaming read, with Content-Length checked up front when present), and returns a clear error, or the content up to the cap marked as truncated, instead of buffering an unbounded body. If the cap is configurable, that's documented in the README.

Reference prototype

#4185 by @neuralmanacle implements a streaming byte cap (2 MB) with tests. It was opened before this repository moved to issues-only contributions, and is closed in favor of this issue; it serves as the reference prototype for the fix, and its author will be credited when the fix ships.