Add configurable limits for HTTP response bodies

Context

The HTTP host collects the complete response body into memory before returning it to Roc:

• src/http.rs:141-165
• specifically response.into_body().collect().await at line 155

A slow response can be constrained with the existing request timeout, but there is no response-size limit. A server can therefore return a very large fixed-length or chunked body and cause excessive memory use or an allocation abort.

This matters for a general-purpose CLI platform because URLs and servers are often outside the application's control.

Suggested direction

Add an explicit maximum response-body size to the HTTP API. Design options include:

• a limit on the shared request configuration;
• a platform-level default plus an opt-in override;
• a separate bounded send operation.

Enforce the limit while consuming frames, rather than collecting first and checking afterward. Return a distinct typed error that callers can distinguish from malformed bodies and network failures.

A later streaming response API can be tracked separately; this issue only needs bounded buffering.

Acceptance criteria

• Callers can select or rely on a documented finite response-body limit.
• Both Content-Length responses and chunked/unknown-length responses are stopped before exceeding the limit.
• Exceeding the limit returns a documented typed error rather than panicking or aborting.
• Tests cover a body just below the limit, exactly at it, above it, and a chunked body above it.
• Existing normal HTTP examples continue to pass on every supported target.

Start in src/http.rs:141-165, especially response.into_body().collect().await at line 155, and inspect the existing request configuration and HTTP examples. Define how the limit is selected and how the typed error is exposed, then enforce it while consuming both fixed-length and chunked bodies. Done means the acceptance tests cover below, exact, above, and chunked limits while existing examples pass on supported targets.