The index-restart fix, measured on the phone

Data cleared so the index was empty and a walk had to run, then one character at a time into the search field over the 20 000-file fixture: Indexing 5600 -> 6300 -> 7100 files, then 'Index updated'. The counter climbing across keystrokes is the fix - each keystroke used to cancel the walk and start it again at the first folder.

docs/EDGE_CASE_TESTING.md

@@ -324,6 +324,24 @@ Driven on the phone through the real UI, with `adb` taps on `uiautomator` dumps.
   the dialog) is still owed. The terminal lost command output halfway through this session, so the driven
   pass stopped after the two checks above rather than being reported as complete.
 
+## The index-restart fix
+
+Reported from use: "the index seems to be recreated at each input of the search bar, and if I switch to
+another library the reindexing starts from begin again". Reproduced and measured on the phone, with the app's
+data cleared first so the index was empty and a walk had to happen, and the 20 000-file fixture in place:
+
+| typed so far | progress row |
+|---|---|
+| `f` | *Indexing 5 600 files…* |
+| `fi` | *Indexing 6 300 files…* |
+| `fil` | *Indexing 7 100 files…* |
+| `file` | *Indexing 7 100 files…*, then *Index updated 2026-10-18 10:52* |
+
+The counter climbing across keystrokes is the fix; before it, each keystroke cancelled the walk (the pass
+ran inside the search's own job, which is replaced on every letter) and the next one began again at the
+first folder, so the row read a fresh, small number every time. The walk finished on the last sample and
+stamped the volume, which is what makes the *next* search cheap instead of another walk.
+
 ## Not verified, and why
 
 - **Long-press multi-select via adb: it works, but not every time.** `input swipe x y x y 900`