BitReader reads a tight packet-sized buffer without an eight-byte slack

[rowan-claude]

Fixes #9.

What the reader gets

new ReadStream( packet, packet.length ) on an exactly-sized byte[] now reads every field, including the last one, instead of throwing ArrayIndexOutOfBoundsException from BitReader.readBits in a release JVM. Any array size works; eight or more bytes of slack past the data is still the fastest shape, and an array with that slack takes exactly the path it took before.

Mechanism

reset copies the final min( bytes, 8 ) bytes into a zero-padded 16-byte tail whenever the array has fewer than eight bytes of slack, recording tailBase, the byte index the tail is based at, and otherwise sets tailBase = Integer.MAX_VALUE. readBits picks its window source with one well-predicted branch, i < tailBase ? LONG_LE.get( data, i ) : LONG_LE.get( tail, i - tailBase ), and loads a single window either way: no allocation per read, and the padding is never interpreted, since bits past the end of the data cannot reach a read's output. This is the serialize.go shape (bitpacker.go, fillTail / readBits), sized for this reader's [1,32] field width.

The slack assert in checkReset is gone; it now asserts bytes <= data.length. Version and STANDARD.md untouched, by house rule. ReadStream's constructor and reset Javadoc still say the array "must extend at least 8 bytes past bytes"; the promise at the top of that file is now kept as written, so I left the file alone. That @param wording is now a performance recommendation rather than a requirement and can follow in its own change if wanted.

Tests

Two new tests in test/serialize/tests/StreamTests.java, both on the reported shape new ReadStream( packet, packet.length ):

• a one-byte packet reads its eight bits and refuses the ninth;
• an eleven-byte packet (3 + 32 + 17 + 32 + 4 bits) is read to its last bit, with windows starting inside the last eight bytes and on the last byte, then again from a copy with three bytes of slack (the band with some slack, but less than a window of it).

On the unfixed reader both throw: the one-byte read needs indices 0..7 of a one-byte array, and the eleven-byte packet's 17-bit read at byte 4 needs 4..11.

What was run, and what was not

Nothing was compiled or run here. This machine has no JDK: /usr/bin/java is the macOS stub, dist/jdk-21.0.12.1 is absent, and there is no /Library/Java, Homebrew, IntelliJ or Android Studio JDK, and no container runtime. So I have not run make test or make test-release, and I have not confirmed the two tests fail on main by execution; the failure on main follows from the index arithmetic above. CI's checked and release runs are the verification for this PR.