fix(qlik): supprime la passe de rattrapage et vérifie que la sélection Date filtre

Le log de la dernière sync montre batches=3 et des lignes « (rattrapage) » : le
chemin par expressions a bien tourné mais a été rejeté (quantité totale nulle),
et c'est le rattrapage qui a de nouveau recopié le total de période dans les mois
manquants — d'où les plateaux à 87 648 d'août à décembre et les « -162 % ».

- Passe de rattrapage SUPPRIMÉE. Elle ré-extrayait un mois vide en ne
  sélectionnant que ses dates ; les master measures ignorant la sélection Date,
  le cube lui renvoyait le total de période. Un mois qu'on ne sait pas extraire
  doit rester absent, jamais rempli d'une valeur plausible.

- Le chemin par expressions vérifie maintenant qu'un champ date filtre RÉELLEMENT
  les faits, ce que personne n'avait pu contrôler tant que seules des mesures
  insensibles à la sélection étaient utilisées. Un total de contrôle
  (Sum(quantite) sans dimension) est comparé avec et sans filtre ; un champ n'est
  retenu que si le total est non nul ET strictement inférieur au total global.
  Candidats : QLIK_DATE_FIELD, Date, Date calendrier, Date_Key (ce dernier
  sélectionné au format AAAAMMJJ). Si aucun ne filtre, l'extraction le dit
  clairement au lieu de produire une fenêtre fausse.

- Diagnostic : échantillon BRUT du cube loggué avant tout filtrage (mois brut,
  mois normalisé, appartenance à la fenêtre, valeurs des cinq mesures), et
  compteur de lignes écartées comme hors fenêtre. Ces deux traces distinguent une
  expression invalide d'un format de dimension Mois inattendu.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu

docs/qlik-integration.md

@@ -140,6 +140,39 @@ jointure avec `articles.artcentrale`.
 
 Lecture seule : sélections en soft lock, objets de session détruits.
 
+### La sélection Date filtre-t-elle seulement quelque chose ?
+
+Question restée sans réponse tant que seules des mesures **insensibles à la
+sélection** étaient utilisées : rien ne prouvait que `Date` bornait quoi que ce
+soit. Le chemin par expressions le vérifie désormais avant d'extraire, avec un
+total de contrôle (`Sum(quantite)` sans dimension) :
+
+```
+[qlik-pw][expr] contrôle Sum(quantite) sans filtre date = 12345678
+[qlik-pw][expr]   champ « Date » → 0 (0% du total sans filtre)
+[qlik-pw][expr]   champ « Date calendrier » → 3456789 (28% du total sans filtre)
+[qlik-pw][expr] champ date retenu : « Date calendrier »
+```
+
+Un champ n'est retenu que s'il donne un total **non nul et strictement inférieur**
+au total sans filtre — 0 % signifie que la sélection ne matche rien, 100 % qu'elle
+n'a aucun effet. Candidats essayés dans l'ordre : `QLIK_DATE_FIELD` (si défini),
+`Date`, `Date calendrier`, `Date_Key` (celui-ci sélectionné au format `AAAAMMJJ`).
+
+Si aucun ne filtre, l'extraction le dit et repart sur l'ancien chemin plutôt que
+de produire une fenêtre fausse.
+
+## La passe de rattrapage a été supprimée
+
+Elle ré-extrayait un mois vide en ne sélectionnant que ses dates. Les master
+measures ignorant la sélection Date, le cube lui renvoyait le **total de période**
+qu'elle recopiait dans chaque mois manquant : d'où les plateaux identiques d'août
+à décembre (87 648 douze mois de suite sur un article) et les tendances
+« −162 % » entièrement fabriquées.
+
+Un mois qu'on ne sait pas extraire doit rester **absent**, jamais rempli d'une
+valeur plausible.
+
 ## Mois vides de la fenêtre glissante (chemin de repli)
 
 Les mesures « N » de l'app sont bornées à une année civile. Quand la fenêtre