STF-383: Fix off-heap memory growth in FileMode.MEMORY

[oschwald]

Summary

• Avoid off-heap buffer cache growth in MEMORY mode — FileChannel.read() into a heap buffer populates sun.nio.ch.Util.BufferCache, a per-thread cache that retains the largest direct buffer ever requested for the JVM lifetime. Under chunked MEMORY mode that meant chunkSize × loading-threads of off-heap pinned permanently. Switching to FileInputStream bypasses the cache. FileMode.MEMORY_MAPPED is unaffected (it uses FileChannel.map, not read).
• Test MEMORY mode under chunkSizes matrix — adds Reader(File, FileMode, int) package-private ctor and a testMemoryMode parametrized over the existing chunkSizes() provider, so the multi-chunk + remainder branch in BufferHolder now has integration coverage.
• Add mise configuration — mise.toml / mise.lock for local Java + Maven version management, matching minfraud-api-java. CI uses actions/setup-java directly and is unaffected.
• Preparing for 4.1.0 — version bump + changelog entry.

Note: the linked Linear ticket suggested Files.readAllBytes() as the fix, but that wouldn't work — Files.readAllBytes is implemented as Channels.newInputStream(FileChannel) and still routes through FileChannel.read → BufferCache. Only java.io.FileInputStream (whose native read(byte[]) copies via SetByteArrayRegion without going through NIO) actually bypasses the cache. This was previously commented on STF-383.

Test plan

• mvn test (199/199 pass, including 3 new chunked MEMORY-mode test runs)
• mvn checkstyle:check clean
• CI matrix passes (Java 17/21/24 × Linux/Windows/macOS)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request addresses an issue with unbounded off-heap memory growth in FileMode.MEMORY by replacing FileChannel.read() with FileInputStream. This change prevents the JDK from caching large direct ByteBuffers in per-thread storage (sun.nio.ch.Util.BufferCache). The update also includes a version bump to 4.1.0, the addition of mise configuration for development environment management, and new tests for memory mode. Feedback was provided regarding potential integer overflow when calculating chunk counts for extremely large databases, which could lead to an incorrectly sized buffers array.

[gemini-code-assist]

The calculation of fullChunks and totalChunks uses an explicit cast from long to int without checking for overflow. If the database size is extremely large relative to the chunkSize (e.g., a multi-terabyte database with a small custom chunkSize), fullChunks could overflow, leading to an incorrectly sized buffers array and potential data corruption or IndexOutOfBoundsException during the reading loop. While MaxMind databases are typically within int range for chunk counts, it is safer to validate this or use Math.toIntExact.

                    var fullChunksLong = size / chunkSize;
                    var remainder = (int) (size % chunkSize);
                    var totalChunksLong = fullChunksLong + (remainder > 0 ? 1 : 0);
                    if (totalChunksLong > Integer.MAX_VALUE) {
                        throw new IOException("Database size exceeds supported chunk count for the given chunkSize");
                    }
                    var totalChunks = (int) totalChunksLong;
                    var fullChunks = (int) fullChunksLong;
                    var buffers = new ByteBuffer[totalChunks];