Add optional direct I/O reads for immutable disk indexes

[tlwillke]

Summary

Adds an optional Linux direct-I/O reader for immutable on-disk indexes. The mapped reader remains the default.

• Read existing V2–V6 records through aligned O_DIRECT buffers, without changing the disk format or writers.
• Batch known traversal and reranking records using bounded Linux kernel AIO. Search ordering, scores, visited counts, filtering and resume behavior are preserved.
• Preserve resident upper-layer adjacency and primary FusedPQ codes. Metadata loading bypasses the optional shared block cache.
• Offer an explicit cache budget (zero by default), with eviction on demand and one pinned file generation per supplier. This caches raw index blocks, not query results or scores.

Usage

try (var readers = ReaderSupplierFactory.openDirect(path, 8, 0);
     var index = OnDiskGraphIndex.load(readers)) {
    // Existing search APIs.
}

Requires JDK 22+ with the native module, native access enabled, and supported little-endian Linux x86_64 or AArch64 storage. ioDepth=0 selects synchronous reads; 1–32 selects batched kernel AIO. A nonzero third argument enables a bounded shared block cache. Unsupported configurations fail explicitly.

See the reader documentation for memory budgets and immutable-file/lifetime requirements.

Validation

On Linux x86_64, JDK 23: 39 focused tests pass, covering actual O_DIRECT descriptor flags, primitive and bulk read parity, sector crossings and EOF, concurrent views/cache eviction, pathname replacement, uncached metadata and speculative-read admission, V2–V6/all stored features, DOT_PRODUCT/L2/COSINE search parity, filters and resume. The 14 existing OnDiskGraphIndex tests also passed.

Performance and larger-than-memory benchmark validation are pending. This draft makes no throughput or variability improvement claim. Allocation fixes remain in #755, separate from this storage change.

[github-actions]

Before you submit for review:

• Does your PR follow guidelines from CONTRIBUTIONS.md?
• Did you summarize what this PR does clearly and concisely?
• Did you include performance data for changes which may be performance impacting?
• Did you include useful docs for any user-facing changes or features?
• Did you include useful javadocs for developer oriented changes, explaining new concepts or key changes?
• Did you rebase your branch onto the latest main for regression testing and PR submission?
• Did you trigger regression testing via Run Bench Main and review results?
• Did you adhere to the code formatting guidelines (TBD)
• Did you group your changes for easy review, providing meaningful descriptions for each commit?
• Did you ensure that all files contain the correct copyright header?
• Did you add documentation for this feature to the release notes directory?

If you did not complete any of these, then please explain below.