[client]Fix memory leak if oom when decompress data.

[loserwang1024]

Purpose

Linked issue: close #2646

Brief change log

Tests

API and Format

Documentation

[loserwang1024]

@platinumhamburg @wuchong , CC

[platinumhamburg]

Thanks for the fix! The approach is consistent with RecordAccumulator.close().

One concern: releaseBytes() only adjusts the allocator's accounting but doesn't actually free the underlying direct memory - those buffers will
remain until GC. This fix prevents the IllegalStateException on close, which is good for avoiding cascading failures, but the actual memory may still
leak temporarily.

For a more robust solution, consider adding try-finally in ZstdArrowCompressionCodec.doDecompress() to ensure temp buffers are released on failure.
But the current fix is acceptable as a defensive measure.

[loserwang1024]

ZstdArrowCompressionCodec.doDecompress() cannot do this, because as i mention in issue:When fail in ZstdArrowCompressionCodec.doDecompress() , we need to release buffers in in org.apache.arrow.vector.VectorLoader#loadBuffers which is the code of arrow.

[loserwang1024]

@platinumhamburg , I modified this PR and add a patched version of Arrow's {@code VectorLoader} to fix this problem. Detail see VectorLoaderTest

[platinumhamburg]

Great work identifying and fixing this Arrow buffer leak! I verified that the upstream Arrow-Java main branch
still has this bug in VectorLoader.loadBuffers() — the decompression loop sits outside the try block, and
buf.close() only runs on the success path. So this patch is definitely necessary.

The fix logic is correct: moving the decompression loop inside the try block and releasing buffers in the finally
clause properly handles both the success path (loadFieldBuffers retains +1, finally close -1) and the error path
(finally close frees all already-decompressed buffers).

Below are only one suggestion to improve maintainability.

[platinumhamburg]

LGTM.