Fix stream buffer double release, header recursion, and eager chunk allocation

[xerial]

Summary

Fixes the issues from the private security reports that 1.1.10.9 didn't cover.

• Double release of pooled buffers in SnappyFramedInputStream. ensureBuffer() and allocateBuffersBasedOnSize() returned buffers to the pool before allocating their replacements. If the allocation threw (e.g. OutOfMemoryError), the fields still pointed at the released buffers, and close() released them again. CachingBufferPool doesn't detect duplicates, so two later streams could get the same backing array. The fields are now cleared immediately after release.
• Unbounded recursion in SnappyInputStream.hasNextChunk(). Each header of a concatenated stream recursed once, so a long run of 16-byte headers overflowed the stack. Headers are now skipped in a loop, the same pattern as snappy-java through 1.1.10.8 Uncontrolled Recursion via SnappyFramedInputStream skippable chunks #731.
• Eager chunk allocation in SnappyInputStream. The compressed-chunk buffer was allocated at the declared chunkSize (up to the 512 MiB MAX_CHUNK_SIZE) before any chunk data was read, so a truncated stream of a few bytes could force a 512 MiB allocation. The buffer now starts at 64 KiB, or the chunk size if smaller, and doubles as data arrives. The uncompressed-buffer allocation is already bounded by the size check added in Fix buffer overflows and unbounded allocations from untrusted input (CVE-2026-90559 and others) #739.
• Raw memory-address APIs. rawCompress(long, long, long) and rawUncompress(long, long, long) take no destination capacity, so they can't be bounds-checked. Their Javadoc now marks them unsafe, says what the caller must check, and points to the bounds-checked ByteBuffer overloads.

Test plan

• 3 new tests in SnappyBoundsCheckTest, all of which fail without the fix:
  • double release, using a pool that simulates OOM and asserts no buffer is released twice
  • 100,000 concatenated headers, which overflowed the stack before
  • a truncated chunk declaring 500 MiB, which must allocate under 100 MB
• ./sbt test: 139 passed

🤖 Generated with Claude Code