Fix Reader stale data, Writer buffer leak, and zero-length write

[lkinley-rythmos]

• Reader.read: clear r.data in direct mode so that a subsequent zero-length block does not copy stale pool data
• Writer.Reset: return data buffer to pool before resetting to prevent a memory leak on reuse
• Writer.ReadFrom: skip write and handler call when read returns zero bytes

[lkinley-rythmos]

Fixes some bugs I have personally run into.

Problem: When the source data is an exact multiple of the block size (e.g., 128MB with 4MB blocks), io.ReadFull returns (0, io.EOF) on the final iteration. ReadFrom still calls w.write(data[:0], true) with empty data. This flows into FrameDataBlock.Compress, which produces a block with Size = 0x80000000 (uncompressed flag set, size=0). This degenerate block is written to the output stream before the proper end-of-stream marker 0x00000000.

Problem: When reading in non-concurrent mode with a user buffer >= block size, the reader uses "direct mode" — decompressing directly into the user's buffer. But r.data is never updated in the direct path. If a block decompresses to 0 bytes, r.read(buf) returns (0, nil). Back in Reader.Read, bn == 0 causes the fallback to copy stale pool data from r.data.

This is the reader-side companion to the first bug. Even with the writer fix, the reader should be robust against degenerate blocks from any encoder.

Problem: Reset() doesn't free w.data back to the pool.

[pierrec]

Nice catch. Can you add tests for each fix please?

[lkinley-rythmos]

Tests added

[pierrec]

@lkinley-rythmos merged your patches but the "testdata/bundle.00001.part00000.lz4" file is missing, so the TestReader_BufferIssue fails. Can you provide it please? Thanks!

[lkinley-rythmos]

I meant to remove that test -- the file is way too big to include.