v0.42.0

The huge-payload conformance test is required, and reads are clamped too.

fix(transport): the read side of the >2 GiB syscall problem. v0.41.0 fixed the writers and said the readers were already hardened — they were hardened against a short read, not against an over-sized read request, and recv_into refuses a buffer above INT_MAX with EINVAL exactly as send does. Because BufferedReader only bypasses its buffer for large requests, whether any one read crossed the line depended on buffer state, so this destroyed roughly one Unix-socket connection in two while the rest passed — and the serve loop logged it at DEBUG and kept accepting. Anyone running the reference over Unix or TCP with multi-gigabyte batches wants this.

test(conformance): VGI_RPC_CONFORMANCE_HUGE is gone; large_payload.echo_binary_over_int32_max now runs by default. Ports may answer it two ways — echo the payload back intact, or refuse it with a typed error that leaves the connection usable (the test proves this with a follow-up call, and annotates the pass with a note:). The second answer exists because the JVM caps a byte[] at INT_MAX elements, so a Java worker cannot materialise 2³¹+1 bytes at any heap size. Silent truncation and deadlock remain failures for every implementation.

The gate is why the read bug survived: the test that exposes it was written a day earlier, was opt-in, and therefore never ran.

--filter gained !pattern exclusion — an exclusion always wins, and a filter made only of exclusions means "everything except these".