Bun parity: set FormData request Content-Length

Upstream coverage

• js/web/fetch/content-length.test.js (corpus position 4121)

Current gap

Home serializes the FormData request body but does not expose its computed byte length through the Node HTTP server request headers. The first assertion expects a numeric content-length header.

Required parity

• serialize FormData once with a stable boundary for a request
• compute Content-Length from the exact encoded multipart bytes
• propagate the numeric header through Fetch and the Node HTTP bridge
• preserve user-supplied header precedence and byte-exact boundary values
• surface serialization/length failures with stable structured Home errors and causal stacks
• add a focused regression and pin the upstream file in the permanent web queue

This is the next ordered step after #348.

Implemented and pushed to main in 69d348a (fix(fetch): set multipart content length).

What landed:

• single-pass FormData request serialization with one stable boundary
• Content-Length computed from the exact UTF-8 multipart bytes
• reuse of the same serialized bytes for transport, preventing boundary/length drift
• user-supplied Content-Length precedence
• Node-compatible lowercase plain-object incoming request headers
• structured ERR_FORM_DATA_SERIALIZE failures with operation, phase, cause, and composed stack
• focused and permanent-queue regressions

Verification:

• exact corpus position 4121: 1 passed, 0 failed, 0 todo, 0 unsupported
• dedicated FormData Content-Length regression: passed
• permanent HTTP/web tail queue: passed
• zig build --cache-dir /private/tmp/home-zig-abi-cache: passed

The ordered frontier now reaches through position 4121. Position 4122 is tracked separately.