[datalog] Reject oversized Java data log records

[virtuald]

The wpilog record size is an unsigned value of up to four bytes, but Java casts
readVarInt() directly to signed int (DataLogReader.java:115-129) and
reconstructs it in another signed int in getNextRecord()
(DataLogReader.java:135-146). The iterator then trusts that result as its next
offset (DataLogIterator.java:19-41) without requiring forward progress.

For a seven-byte record header, encoded size 0xfffffff9 becomes -7.
ByteBuffer.limit() reduces the duplicate's position and yields an empty data
slice, while pos + headerLen + size equals the original pos. The record is
accepted forever at the same offset.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1e61bf5115

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid materializing discarded records while advancing

When clients use the standard hasNext()/next() iteration pattern, hasNext() calls getRecordInfo() once and next() calls it twice more—through both getRecord() and this method. Each log record is therefore parsed three times, with two temporary DataLogRecord, RecordInfo, and ByteBuffer views discarded; large wpilog files will incur avoidable CPU, allocation, and GC overhead compared with the previous constant-time hasNext() and lightweight advancement. Cache the parsed record in the iterator or separate bounds validation/position calculation from record materialization.

Useful? React with 👍 / 👎.