docs(lessons): "permanent/tot" nie ohne Transienz-Gegenprobe (supprime war transient)

Lehre aus v1.7.210->211: Mega-Debrid "Fichier supprime" als permanent annehmen
ohne zu pruefen, ob derselbe Link je danach ein OK bekam. Intersection(failed, ok)
!= leer -> transient. Plus die Account/Link-permanent/dieser-Versuch-Linse.

tasks/lessons.md

@@ -1,5 +1,31 @@
 # Lessons
 
+## 2026-06-17 — "Permanent/tot" NIE annehmen ohne Transienz-Gegenprobe (supprimé war transient)
+
+**Muster:** Mega-Debrid lieferte 479x "Fichier supprimé chez l'hébergeur". Ich nahm
+"supprimé = gelöscht = toter Link" als permanent an, baute Fix (sofort scheitern, kein
+Web-Fallback) + released v1.7.210. Der User fragte: "welcher Link soll tot sein, hast du
+das hinterfragt?" Gegenprobe an den Logs: von 18 Links mit "supprimé" haben **4 Sekunden
+später ein OK** geliefert (1x Web, 3x API-Retry 7–66s). Der Fehler war TRANSIENT. 210
+hätte erholbare Links dauerhaft gekillt. Korrektur v1.7.211: temporär statt permanent.
+
+**Regel:**
+- Bevor ein Fehler als permanent/fatal/tot klassifiziert wird: an echten Daten prüfen, ob
+  derselbe Link/dieselbe Ressource mit demselben Fehler **jemals danach ein OK** bekam.
+  Intersection(failed-links, ok-links) ≠ ∅ → transient → permanent-Klassifizierung ist
+  falsch. Wortbedeutung ("supprimé"=gelöscht, "deleted") beweist KEINE Permanenz —
+  besonders bei flakigen Multihostern (Mega-Debrid), die per-Link kurzzeitig falsch melden.
+- **Die Linse (Advisor):** bei jedem Fehlersignal fragen — ist das über den ACCOUNT
+  (→ ggf. Cooldown), über den LINK PERMANENT (→ Item scheitern), oder nur über DIESEN
+  VERSUCH (→ Retry)? Beide Bugs hier (Account-Cooldown-Vergiftung UND falsch-permanent)
+  waren derselbe Fehler: ein Per-Versuch-Signal als account-/link-globaler Zustand behandelt.
+- Wieder die 05-31-Regel verletzt (empirisch bestätigen vor Release). Wenn der User
+  skeptisch nachfragt ("hast du das hinterfragt?"), ist das fast immer ein echter
+  ungeprüfter Sprung — sofort an Daten gegenprüfen, nicht verteidigen.
+- Retry-Pacing verifizieren, nicht annehmen: cooldownMs:0 entfernt Account-Cooldown,
+  aber der Download-Manager bremst per 5s-Exponential-Backoff (unrestrictDelayMs) pro
+  Item — getraced, weit unter Mega-Debrid 50 req/s. Account-Cooldown ≠ Retry-Pacing.
+
 ## 2026-05-31 — Fix-Diagnose EMPIRISCH bestätigen, bevor man released (Timeout ≠ Account-Hänger)
 
 **Muster:** "acc2/acc3 nie versucht" wurde als "acc1 hängt → Per-Account-Timeout +