wasi/http: guest content-length mismatch is silently corrected instead of HTTP-request-body-size #230

Found while comparing outbound wasi:http behavior against wasmtime-wasi-http 47.0.3 (src/p3/).

wasmtime validates the streamed request body against the guest's content-length header frame-by-frame and fails the transmission with HTTP-request-body-size on mismatch (p3/request.rs:164-207, body.with_content_length(..., ErrorCode::HttpRequestBodySize)). Response bodies are deliberately not validated (default_send_request doc: "This function performs no Content-Length validation") — the asymmetry is upstream policy.

We do neither: request bodies are buffered (recorded divergence, wasi/src/http.ts:51-54) and fetch computes the real content-length from the buffer, so a guest-set content-length that disagrees with the actual body is silently corrected rather than erred. A guest bug that fails loudly on wasmtime is invisible here — and the request that reaches the server is subtly different from the one the guest described.

Suggested fix

Cheap, because the body is already fully buffered before send: after collectBody (wasi/src/http.ts:984-987), if the guest's fields carry a content-length, compare it to the collected byte length and fail the transmission with HTTP-request-body-size(some(actual)) on mismatch, matching wasmtime's variant. Response side stays unvalidated, matching upstream.

Belongs in the recorded-divergences header (wasi/src/http.ts:40-60) either way.