fix(mail) : stop le spam GlitchTip de sync (reconnexion AUTHENTICATIONFAILED + double-log)

Un seul echec de dossier (empty response) generait 4 events GlitchTip :
- le bloc de detection de suppression rappelait listMessages quand le
  fetch initial avait echoue, forcant une reconnexion IMAP refusee par OVH
  (AUTHENTICATIONFAILED, throttling) ;
- chaque echec etait logge 2x en error (provider + service).

Fix :
- garde `if (null !== $remoteHeaders)` autour de la detection de
  suppression : si le fetch a echoue, on saute le diff (reprise au
  cycle suivant), plus de reconnexion parasite ;
- le log service des MailProviderException passe en warning (le provider
  reste la source unique au niveau error pour GlitchTip, couvre aussi les
  chemins HTTP).

Net : 1 event GlitchTip par echec de dossier.
Test de regression : testSyncFolderDoesNotRefetchMessagesWhenInitialFetchFails.

docs/mail-integration.md

@@ -28,6 +28,12 @@
 > 1. **Double-encodage UTF7-IMAP** : `listFolders()` stocke `$folder->path` = nom **brut UTF7-IMAP** (webklex `Folder::$path`). `ImapMailProvider` appelait ensuite `$client->getFolder($path)` qui ré-encode UTF8→UTF7-IMAP (`Client::getFolderByPath`, `$utf7=false`) → le `&` (shift UTF7) est ré-encodé → dossiers à accents/specials introuvables. **Fix** : `getFolder($path, null, utf7: true)` partout dans `ImapMailProvider` (les paths sont déjà UTF7-IMAP). Résout les ~7 dossiers à encodage spécial qui étaient « skippés ».
 > 2. **Dossiers fantômes jamais purgés** : `syncFolderStructure()` gardait en DB les dossiers disparus du serveur (Trash vidé, dossiers RH supprimés) → re-tentés à chaque cycle → `listMessages` → "not found" → log error en boucle. **Fix** : `syncFolderStructure()` retourne le set des chemins **présents sur le serveur** ; `doSyncAll()` skip silencieusement les dossiers DB absents de ce set (gardés en DB pour les liens messages/tâches, mais plus synchronisés). Si `listFolders` échoue (retour `null`), fallback = sync de tous les dossiers connus (comportement historique).
 >
+> ### Bugs corrigés 2026-06-30 (spam GlitchTip `AUTHENTICATIONFAILED` + double-log)
+> 4 events GlitchTip pour **un seul** échec de dossier (`INBOX/RH/LUCILE NEAU`, release 0.4.54). Root cause **différente** du fix du 29/06 (le « Folder not found » est bien éteint). Deux amplificateurs dans `MailSyncService::syncFolder` :
+> 1. **Re-fetch après échec** : quand le `listMessages` initial échoue (`empty response`), le bloc de détection de suppression **rappelait `listMessages`** (`$remoteHeaders === null`). Ce 2ᵉ appel forçait une **reconnexion IMAP** que OVH refusait (`AUTHENTICATIONFAILED`, throttling) → 2 events parasites. **Fix** : le bloc deletion est gardé par `if (null !== $remoteHeaders)` — si le fetch a échoué, on saute la détection de suppression (impossible de differ sans liste distante fiable ; reprise au cycle suivant). Les credentials sont valides — l'auth-fail venait de la reconnexion, pas du mot de passe.
+> 2. **Double-log error** : provider (`ImapMailProvider::listMessages`, error) **et** service (`syncFolder[...] listMessages failed`, error) logguaient la même `MailProviderException` → 2 issues GlitchTip. **Fix** : le log service `MailProviderException` passe en `warning` (le provider reste la source unique au niveau `error` pour GlitchTip, ce qui couvre aussi les chemins HTTP où les controllers catchent sans logger). Net : 1 event GlitchTip par échec de dossier.
+> Test de régression : `MailSyncServiceTest::testSyncFolderDoesNotRefetchMessagesWhenInitialFetchFails` (assert `listMessages` appelé **une** seule fois).
+>
 > ### Points en suspens / à savoir
 > - **Mise à jour auto** = cron OS lançant `make mail-sync` toutes les 10 min (cf `docs/mail-cron-setup.md`). **Pas configuré en dev** — lancer à la main.
 > - **Bouton "Actualiser"** : dispatch async Messenger (`MailSyncRequested → async`). Sans worker `messenger:consume async` qui tourne, les demandes s'empilent sans s'exécuter. En prod : supervisor. En dev : lancer un worker.