perf(cfapi): amortissement retry hydratation placeholder (backoff, dédup Open, resume offset)

[CCoupel]

Issue de suivi — Phase 3 du plan de #160 (_work/reports/plan-20260812-102022.md), volontairement exclue du scope de #160 (Option A du GATE 2 : correctif ciblé au plugin MooseFS, cette phase devient une défense en profondeur séparée).

Contexte : #160 a identifié que chaque échec de lecture de chunk remonte jusqu'à faire échouer l'Open du placeholder CF API. Windows relance alors l'Open intégralement, sans backoff — le téléchargement repart de zéro. Une fois la cause racine de #160 corrigée (keepalive MooseFS mal géré), ce mécanisme de relance sans garde-fou reste un point de fragilité générique pour tout backend, pas seulement MooseFS, en cas d'erreur transitoire.

Tâches (détail dans le plan de #160, Phase 3, fichier internal/cfapi/) :

• Borner et espacer les relances de téléchargement de placeholder (backoff + limite de tentatives par fichier)
• Déduplication des Open concurrents sur un même chemin (un seul téléchargement en vol par fichier)
• Ne pas repartir de l'offset 0 après un échec partiel (préserver la progression d'hydratation)

Risque si inclus dans #160 : modifie le chemin d'hydratation commun à tous les backends (WebDAV, Local, MooseFS), donc risque de régression plus large que le scope de #160.

---

Note : voir aussi #162 (perte de données silencieuse dans internal/placeholder, sujet apparenté mais distinct — chemin cfapi ici, chemin FUSE/placeholder là-bas).

[CCoupel]

Défauts analogues détectés côté cfapi (Phase 3 du plan #160) — Le chemin d'hydratation Cloud Filter API souffre de vulnérabilités parallèles au chemin FUSE/placeholder identifiées dans ce bugfix :

Extrait de la note d'architecture du plan (plan-20260812-102022.md) :

Champ	FUSE/Placeholder (ce bugfix #160/#162)	Cloud Filter API (cet issue #161)	Défaut
Retry + backoff	✅ Implémenté (tâche 7-10, 17-18)	❌ Aucun dans	Relances sans délai, pas de backoff exponentiel
Échéance par tentative	✅ Timeout 3 min par téléchargement	❌ context.Background() sans délai dans provider.go:545	Risque hang indéfini
Gestion erreur retryable	✅ Distinction isStaleConnErr typée	❌ ReportError toujours E_FAIL sans distinction (provider.go:441-449)	Perte d'info diagnostic
Déduplication concurrent	✅ downloadCoordinator (tâche 16)	❌ Pas de dédup FETCH_DATA concurrent	Téléchargements dupliqués, surcharge réseau

Recommandations d'intégration :

1. Ajouter retry + backoff exponentiel à OnFetchData (modèle similaire tâche 17-18 du plan, ou réutiliser internal/backoff.MooseFS si compatible)
2. Remplacer context.Background() par context.WithTimeout(ctx, 3*time.Minute) ou configurable
3. Implémenter ReportError avec distinction CFE_NETWORK_TIMEOUT / CFE_INVALID_RANGE / CFE_GENERIC pour diagnostic fine
4. Implémenter coordinateur de dédup FETCH_DATA par chemin (identique tâche 16)

Cette issue reste volontairement exclue du scope #160 (risque de régression sur tous les backends) et doit être traitée en suivi séparé.

[CCoupel]

Découverte annexe du plan #163 — Lors de l'élargissement de la granularité MooseFS (B2), incohérence détectée : Backend.ChunkSize()=64 MiB (retourné au lecteur CF API/placeholder) vs ancienne précondition readEC4At size≤64 KiB d'avant #163.

Résolution : l'élargissement de readEC4At à 4 MiB (et gestion générique jusqu'à taille d'un chunk complet par découpe sur frontières de shard) résout incidemment cette incohérence — le lecteur CF API peut désormais demander jusqu'à 64 MiB, readEC4At gère n'importe quelle taille tant qu'elle reste dans un chunk.

Statut : Résolue de facto, mais sans validation end-to-end du chemin CF API (hors scope #163, emprunte internal/placeholder FUSE qui n'utilise pas readEC4At directement). À vérifier/confirmer dans ce cycle #161 si souhaité, mais pas un blocage puisque la précondition est maintenant satisfaite par le code.