[Aschenbath]

Split out of #1131 at review.

SearchIndex opens its reader with Tantivy's default OnCommitWithDelay policy, and every write (index_chunks, clear, delete_document) also calls reader.reload() itself under the writer lock so the write is readable right away. With both active, two reloads can race. In Tantivy 0.26.1, InnerIndexReader::reload builds a searcher from the segment metas it reads and then calls ArcSwap::store unconditionally. If the watcher's reload reads the metas for commit N, the explicit reload after commit N+1 then stores N+1, and the watcher finishes last, the reader goes back to N and the chunk just indexed disappears from search until the next reload.

This came up in #1131's local full workspace run (Linux x86_64, 2 CPUs, PostgreSQL 16/pgvector): a chat citation regression could not find a chunk it had just indexed.

The reader now uses ReloadPolicy::Manual. Nothing that was visible before stops being visible: the server holds the index's only IndexWriter (Tantivy's directory lock rules out a second one), and every commit through it is already followed by an explicit reload. A comment above the builder says why.

Not run locally on this branch: I don't build Rust on this machine, so CI's cargo test --workspace is the check. The change is the reader construction only; the existing citation and search tests cover reads after writes. There is no deterministic test for the race, because it depends on the watcher thread's timing.

[WaylandYang]

Thanks — every commit already reloads under the writer lock and the server holds the only writer, so Manual loses nothing. Merging.