Apply sequential read advice during vector merges

[jimczi]

Lucene brackets a merge with getMergeInstance() and finishMerge() on the reader it is
handed: the first lets a reader prepare for merging (the flat vector readers use it to switch
their input from the DataAccessHint.RANDOM advice used for search to SEQUENTIAL), the
second restores the search access pattern afterwards. Both calls have to travel the whole
reader chain to reach the reader that owns the raw vector input. Three links in that chain
did not pass them on.

IVFVectorsReader (bbq_disk) overrode neither, so the flat vector reader kept RANDOM
advice for the entire merge, disabling read-ahead on the sequential scans a merge performs
(checkIntegrity() and the vector copy). getMergeInstance() now returns a copy of the
reader — via a copy constructor — backed by the flat readers' merge instances, and
finishMerge() delegates to them. Only the flat vectors are affected: the centroid and
posting list inputs (ivfCentroids / ivfClusters) are opened with the default context and
already use read-ahead advice, so they are left unchanged.

MergeReaderWrapper returned its merge reader without calling getMergeInstance() on it,
and did not implement finishMerge() at all, so both calls stopped at the wrapper. This is
the reader that sits in front of the raw vectors whenever direct I/O is enabled for them
(on_disk_rescore: true), which means the fix above had no effect at all in that
configuration — the call reached the wrapper and went no further. Both are now delegated.

ES818BinaryQuantizedVectorsReader (bbq_hnsw) had the opposite half of the problem: it
built a merge instance from the raw reader but never told that reader the merge had finished.
Since the flat reader mutates shared state and relies on finishMerge() to revert it, the raw
vector input stayed on sequential advice after the first merge — the wrong access pattern for
the rescoring path that reads it next. finishMerge() now delegates.

MergeReaderWrapperTests covers the wrapper's half of the contract with recording readers:
that both calls reach the merge reader, and that the search reader is never asked for a merge
instance nor told to finish one. The test fails on both counts without the production change.

Known gap left in place: Lucene104ScalarQuantizedVectorsReader (int8_hnsw / int4_hnsw)
overrides neither method, so nothing below it is reached for those field types. It keeps its
rawVectorsReader private with no copy constructor, so the equivalent fix cannot be made from
the Elasticsearch subclass and belongs upstream.

[github-actions]

🔍 Preview links for changed docs

⏳ Building and deploying preview... View progress

This comment will be updated with preview links when the build is complete.

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[elasticsearchmachine]

Hi @jimczi, I've updated the changelog YAML for you.

[elasticsearchmachine]

Hi @jimczi, I've updated the changelog YAML for you.

[benwtrent]

I think this is good.

[thecoop]

It's worth re-evaluating this in light of #155919, which removes the page cache from merges entirely