v0.21.2 — an unholdable request body no longer wedges the connection

Fixed

A request body larger than this runtime can hold killed the whole connection.

The cross-language conformance suite sends 2**31 + 1 bytes to see what a port does. Java cannot hold that at any heap size or allocator limit — an ArrowBuf is int-indexed — and the suite treats a typed refusal as a conforming answer, "provided it left the connection usable". Ours did not: the launcher lane went 59 passed / 41 failed, with everything after the large payload dying on a broken pipe.

Two defects, and only fixing both helps:

• Stock MessageChannelReader.readNext() reads the message header and then allocates the body in one step. When that allocation threw, the header was already consumed while the body bytes were still queued, and serveOne caught the Arrow OOM, logged it and returned — never answering the caller and never draining. VgiMessageReader now re-implements readNext() so the body length is known where the failure happens, drains exactly that many bytes, and raises OversizedMessageException, which is answered as an error for that one call.
• Draining the body alone was still not enough. A request is schema + batch + EOS, and the marker the caller's writer.close() emits was left queued to be misread as the next call's schema — so the connection died one call later, indistinguishable from the original wedge. That path now drains to EOS like every other exit from serveOne.

Conformance on the launcher lane is now 104 total, 100 passed, 0 failed; the pytest suite over pipe/subprocess/unix passes 562.

No API changes.