Encapsulate payload size pre-flight in the payload reader (#153)

[jonbaldie]

Closes #153

The enqueue route used to parse Content-Length and build its own 413 response. The payload reader enforced the streamed limit on its own. Now readAndValidatePayload handles both.

• readAndValidatePayload(stream, options) takes ReadPayloadOptions { maxBytes?, contentLength? }. It throws PayloadTooLargeError before reading the body when the declared length is over the limit.
• The streamed byte limit is enforced exactly as before. A missing, small, empty or non-numeric declared length doesn't weaken it.
• The route passes the header through. Both overflow paths go through the existing PayloadTooLargeError → 413 Payload too large mapping.
• It still reads the length with parseInt, so the pre-flight rule is unchanged.

Tests:

• New payload-seam tests: an oversized declared length rejects with the stream left unlocked and unread; a declared length exactly at the limit is accepted; the streamed limit still applies with "5", "not-a-number", "" and null lengths.
• New handler test: Content-Length: 1048576 is accepted.
• Existing handler and e2e tests for the 413 paths pass unchanged.
• Full suite: 371 passed.
• Smoke test against the running server: an oversized Content-Length with a tiny body gets 413, an oversized chunked stream gets 413, and an exactly 1 MiB body gets 200.

🤖 Generated with Claude Code