bachir
f7e7ae3265
Remplace le "charge tout puis filtre côté client" (filteredRows()) par un nouvel endpoint /lignes/api/lignes (LedgerRowsController), qui pousse tous les filtres de la barre d'outils dans une seule requête Entity/Field Query API (pas de SQL brut) -- y compris à travers la relation field_repartition -> field_compte (paragraph -> taxonomie), confirmé fonctionner empiriquement avant d'écrire le contrôleur. `rows` ne contient donc plus que ce qui est à la fois dans la fenêtre de dates ET dans les filtres actifs ; la fenêtre glissante elle-même (loadOlder/loadNewer/ ensureScrollable) est inchangée, seul ce qui la peuple change. Ajouts : - Nouveau filtre "Libellé / Détails" (recherche plein texte sur field_notes ou le titre), débouncé côté client (350ms). - filterYear (l'"Année" dédiée) passe par le même endpoint via son paramètre "annee". - mergeChangedRows() (le merge du polling) tient maintenant compte des filtres actifs : une ligne qui ne correspond plus après un changement est retirée de `rows`, une ligne qui correspond nouvellement est ajoutée -- polling lui-même reste global/non filtré, seul le merge est filter-aware. JSON:API reste utilisé pour ce que l'endroit filtré ne couvre pas : le groupe entrée/sorties liées (fetchLignesByNids) et le polling (fetchChangedSince), tous deux indépendants d'une plage de dates+filtres. Testé en local : chaque filtre individuellement et combiné (compte+q, client+type), widening de fenêtre sous filtre restrictif, restauration combinée depuis le hash au reload, modale d'édition + reloadWindow après fermeture, polling sans erreur.