Let the structure reading vectors say how they are read

[jimczi]

A format opening a file can attach hints to say what it holds and how it will be read, and a
directory can act on them. MMapDirectory turns them into madvise calls if an application asks it
to. Today the vectors formats get two things wrong there.

The first is who is talking. How a file is read depends on what is reading it, not on what it holds.
The same flat vectors are walked all over the place under an HNSW graph and scanned front to back by
an exact search, yet it was the flat format claiming random access for both. And during a merge it
could say nothing at all, because IOContext.merge(...).withHints(...) returns the same context and
drops the hints, as does flush(...).

So merge and flush contexts now carry hints, and the HNSW formats carry the random hint rather than
the flat ones, at search time and while a merge builds the graph. Formats that can be wrapped follow
their caller; a format reading its own files, like the HNSW graph or the Faiss index, still sets its
own.

The second is that RANDOM is too coarse to act on. It is really two claims in one: don't read
ahead, and don't bother remembering these pages. On mmap they come together, since random advice
takes a mapping out of the page reclaim's recency tracking. That is what you want for stored fields,
term vectors and the raw vectors kept only to rescore, which land somewhere else on every query. It
is the opposite of what you want for the vectors a graph walks, which are the ones you most want to
keep in memory. So NoReuseHint splits them: those three set it, the vectors under a graph don't.

Nothing behaves differently here. The point is that an application can now tell the two apart and
pick, which it could not do before.