The new `max_request_body_size` limit is enforced only through the new `manager.asgi_app` wrapper — `StreamableHTTPSessionManager.handle_request` remains a public, documented ASGI entry point with no size check, so existing code that mounts `handle_request` directly (as the SDK's own tests and, until this PR, `examples/stories/legacy_routing/README.md` do) silently gets no limit. That contradicts docs/migration.md's unconditional claim that "V2 applies a 4 MiB default limit" and the class docstr

RequestBodyLimitMiddleware caps only the sum of body bytes but caches one ASGI message dict (~220 bytes of object overhead) per `http.request` message, so a client trickling a chunked POST in 1-byte segments can force ~4M cached dicts (~1 GB resident) per request before the default 4 MiB limit trips — a ~200x amplification of exactly the memory bound this PR adds. Coalescing the cached body chunks into a single `bytearray` and replaying one synthesized message would bound memory at `max_body_siz