fix(search): wait for merge threads before dropping the bulk writer

[Azur1337]

RoomIndex::bulk_execute oepns a tantivy IndexWriter, commits, and then lets it drop without calling wait_merging_threads(). The writers background merge threads can outlive it and still be running when the next bulk_execute opens a new writer on the same index, so the two race over the same segments

During bulk indexing (e.g. backfilling a room history) this surfaces as

      tantivy::indexer::segment_manager: couldn't find segment in SegmentManager

warnings and leaves the index more fragmented than necessary

To fix this, we wait for the writers merge threads to finish before it is dropped at the end of bulk_execute. No public api change

---

• I've documented the public API changes in the appropriate changelog files (see [Writing changelog entries][pull-request-template-changelog]).
• This PR was made with the help of AI.

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.91%. Comparing base (7bf142a) to head (fa5f4d5).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-search/src/index/mod.rs	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6731      +/-   ##
==========================================
- Coverage   89.92%   89.91%   -0.02%     
==========================================
  Files         398      398              
  Lines      111157   111161       +4     
  Branches   111157   111161       +4     
==========================================
- Hits        99954    99946       -8     
- Misses       7400     7412      +12     
  Partials     3803     3803              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will improve performance by 98.38%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
✅ 49 untouched benchmarks

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	Restore session [memory store]	224.5 ms	113.1 ms	+98.38%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing Azur1337:fix/search-bulk-execute-wait-merges (fa5f4d5) with main (7bf142a)}