fix(java): reject encoder push length exceeding input buffer capacity

[3412-cloud]

Summary

EncoderJNI.Wrapper.push(int length) validates only length >= 0. It does not validate that length <= inputBuffer.capacity(). nativePush() stores input_length without an upper bound and passes it as available_in to BrotliEncoderCompressStream, which reads *available_in bytes from the input buffer. A caller invoking new EncoderJNI.Wrapper(1).push(PROCESS, 32) with a 1-byte input buffer causes a heap out-of-bounds read of 32 bytes.

This is the same bug that was fixed in the DECODER in commit 2dc2a5f ("fix(java): reject decoder push length exceeding input buffer capacity"), which added an upper-bound check in Wrapper.push() plus native defense-in-depth (allocation size stored in the handle). The encoder was left unfixed.

Fix (mirroring the decoder fix 2dc2a5f)

1. Java check in EncoderJNI.Wrapper.push: reject length > inputBuffer.capacity() with IllegalArgumentException.
2. Native defense-in-depth: store the allocation size in EncoderHandle and reject oversized input_length in nativePush().
3. Regression test (EncoderJNITest): rejection of oversized/negative lengths and a valid round trip with length == capacity.

Verification

Before the fix, ASAN reports a heap-buffer-overflow READ of size 32 (memcpy in RingBufferWrite, c/enc/ringbuffer.h:115 via CopyInputToRingBuffer -> BrotliEncoderCompressStream). After the fix, the same trigger raises IllegalArgumentException: block length exceeds input buffer capacity.

Reported privately to Google OSS VRP (issue 549278294); coordinated disclosure, not public.