docs: state the real cost of skipping compression on streamed responses

[TurkeyMan]

Follow-up to #489, docs only.

The UX_TODO note I wrote there said streamed responses skip compression "trading a little link time for bounded memory". Measured, that undersells it: goodwe_ems.conf is 135,658 bytes and gzips to 27,657, so ~4.9x. The 64KB threshold sends the most compressible content (large text) down the uncompressed path, so the config editor's own files are exactly the ones that now transfer at full size, where the old buffered path gzipped them.

The note now states the real ratio, says plainly that clients should not assume large files arrive compressed, and records why it isn't simply fixed: a compressed body of unknown length needs Transfer-Encoding: chunked (Content-Length counts post-encoding octets, so it can't be known up front), and that needs an incremental compressor. urt.zip has none: zlib_compress/gzip_compress are whole-buffer, and the internals are structurally so (single BFINAL=1 block, match finder holding raw pointers into the source, output accumulated in one buffer).

Deferred deliberately, not overlooked. Worth noting websocket permessage-deflate queues behind the same missing piece.

🤖 Generated with Claude Code