fix: indexation inversée non-bloquante — run_in_executor

L'étape 'Building inverted index...' au démarrage bloquait l'event loop
asyncio, empêchant le serveur de répondre aux requêtes HTTP (navigation,
refresh) jusqu'à la fin de l'indexation.

- init_inverted_index() exécuté dans ThreadPoolExecutor via run_in_executor
- get_inverted_index() ne fait plus de rebuild auto bloquant
- Le serveur répond immédiatement, même pendant l'indexation

backend/search.py

@@ -672,14 +672,13 @@ def init_inverted_index():
 def get_inverted_index() -> InvertedIndex:
     """Return the singleton inverted index.
 
-    Auto-builds on first call if the index has files but the inverted
-    index hasn't been built yet (fallback for paths that don't go through
-    ``init_inverted_index()``).
+    The inverted index is built once at startup in a background thread.
+    If called before the build completes, returns an empty index (searches
+    will return no results until the build finishes).
+
+    No automatic rebuild — the startup sequence handles the initial build.
+    Incremental updates are applied via ``update_inverted_index()``.
     """
-    if _inverted_index.doc_count == 0 and any(
-        vdata.get("files") for vdata in index.values()
-    ):
-        _inverted_index.rebuild()
     return _inverted_index