Note short-read bug fix in 4.1.0 changelog

The prior multi-chunk MEMORY load loop (introduced in 4.0.0 by
2a1fa7f, "Make buffers read-only for all paths") called
FileChannel.read(ByteBuffer) and trusted it to fully fill the
destination — a short read would have silently truncated the
in-memory database. The new readFully helper retries until each
chunk is full, so this is incidentally fixed. Worth noting in the
changelog so anyone investigating a >2GB MEMORY-mode corruption can
trace it back.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: oschwald

CHANGELOG.md

@@ -12,6 +12,13 @@ CHANGELOG
   threads could grow this cache without bound. The reader now uses
   `FileInputStream` for `MEMORY` mode, which bypasses the cache.
   `FileMode.MEMORY_MAPPED` was unaffected.
+* Fixed a latent short-read bug in the multi-chunk `FileMode.MEMORY`
+  load path introduced in 4.0.0. `FileChannel.read(ByteBuffer)` is not
+  contractually obligated to fully fill the destination buffer; a
+  short read could have caused silent truncation of an in-memory
+  database. Affects databases larger than ~2GB (the default chunk
+  size). The new chunked read loop retries until each chunk is fully
+  populated.
 
 4.0.2 (2025-12-08)
 ------------------