Decode a multipart upload from the request bytes, not from a String

[hellerve]

The request buffer was turned into a String before parsing, so a multipart/form-data body was cut at its first NUL byte, taking the closing delimiter with it. The handler got a Result.Success carrying no parts and had nothing to check.

Reproduced at the same shape the issue reports: a 123-byte body measures 109 as a String, decodes to 0 parts, and the same body as text gives 1.

• Form.decode-multipart-request-bytes decodes via http's Multipart.parse-bytes, yielding BinaryParts with (Array Byte) bodies. Request.body stays a String, which is fine for every other route.
• the server keeps the in-flight request's raw body bytes alongside the parsed request, since a handler only ever sees &Request and &params. Set once per request before the hooks and the handler; a buffer whose framing does not parse leaves an empty body rather than the previous request's.
• chunked bodies are now dechunked over the buffer's bytes. The old path ran TransferEncoding.dechunk on the truncated String body, so a chunked binary upload was answered with a 400. This leaves one chunk decoder in the request path rather than two.

Tests: 403 in test/web.carp (7 new, covering trailing/embedded/all-NUL payloads, the chunked framing, and the fact that the String path still loses the part, which is why the byte one exists), 155 websocket, 18 cors. Two new end-to-end checks in smoke.sh upload a real binary file through a running server, plain and chunked.

Closes #66