Optimize import memory, SQLite and FTS5 search

[cerede2000]

Ce qui change

• stabilise la RAM après les imports avec un pool fixe, MALLOC_ARENA_MAX=2, collecte explicite et malloc_trim(0) sous Linux ;
• checkpoint/tronque le WAL après migration et import, avec auto-checkpoint et journal résiduel limité à 16 Mio ;
• remplace la recherche LIKE par un index SQLite FTS5 Unicode synchronisé par triggers ;
• applique des projections SQL strictes aux listes de programmes et chaînes ;
• documente la migration automatique, la sauvegarde et l’espace disque requis.

Pourquoi

Les imports 7z libéraient leurs objets mais l’allocateur natif conservait une part importante du pic RSS. La recherche parcourait aussi l’intégralité des titres, sous-titres et descriptions. Un WAL volumineux restait enfin présent après les transactions d’import.

Impact

La migration FTS5 s’exécute automatiquement au premier démarrage. Elle conserve les données existantes, augmente la taille de la base pour stocker l’index et peut prolonger le premier démarrage. Une sauvegarde préalable est documentée.

Validation

• Ruff et format : OK
• Backend : 134 tests passés
• Frontend : ESLint, 90 tests et build passés
• Migration v1.16.0 vers FTS5 testée avec données préexistantes
• Triggers FTS insert/update/delete et plan d’index virtuel testés
• YAML, script d’entrée et diff vérifiés
• Benchmark synthétique 100 000 programmes : recherche sélective ~40 ms avec LIKE, <10 ms avec FTS5 ; construction de l’index ~0,18 s