Renaming-Logging: lueckenloses Desktop-Protokoll pro Sitzung + Post-Rename-Verifikation

User-Goal: bei kuenftigen Renaming-Problemen eine vollstaendige, sofort auffindbare Uebersicht —
JEDER Umbenenn-/Verschiebevorgang protokolliert UND danach verifiziert (liegt die Datei wirklich
unter dem Zielnamen? Quelle weg? richtige Schreibweise?).

- NEU desktop-rename-log.ts: pro Sitzung <Desktop>/Downloader-Log/rename-session_<ts>.txt; Ordner
  selbstheilend (mkdir recursive vor jedem Write -> auch nach Loeschung zur Laufzeit sofort wieder
  da). Synchroner Append, Schreibfehler verschluckt (bricht nie einen Download).
- verifyRename (sync) + verifyRenameAsync (Hot-Path): prueft Ziel-Existenz, echten On-Disk-Namen
  (case-genau via readdir), Quell-Abwesenheit; Level INFO/WARN/ERROR. Nutzt denselben \?\-Long-
  Path-Prefix wie der echte Rename (sonst falsche Urteile auf langen Scene-Pfaden).
- download-manager: renamePathWithExdevFallback = verifizierter Wrapper um die unveraenderte
  Raw-Logik (deckt alle Media-Renames ab) + 3 Sync-Sites (startup-Dedup, Deobfuskation, Suffix-Fix)
  via logVerifiedRenameSync; logRenameProcess spiegelt ins Desktop-Log.
- app-controller init/shutdown (getPath("desktop") gegen Startup-Crash abgesichert); support-bundle
  packt das Log mit ein.

Adversarialer Review-Workflow (4 Linsen) fand + behoben: Long-Path-Verify-Bug (falsches OK
maskiert halb-fertigen Move), readdir-Fehler-False-OK, sync-I/O im Hot-Path, getPath-Guard,
Test-Temp-Cleanup. tsc 9 (Baseline), 663 Tests (+7 neue), Build gruen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

tasks/lessons.md

@@ -135,3 +135,25 @@ Streak (3× hintereinander leer → geparkt), nicht der einmalige Wortlaut.
 Zähler. Ein E2E-Test muss eine ECHTE leere Antwort durch den realen Einstiegspunkt
 (`unrestrictWithAccounts` → `classifyAccountFailure` → catch → Park) treiben, sonst bleibt
 unbewiesen, dass der Produktionspfad das Signal überhaupt setzt.
+
+## 2026-06-01 — Ein Verifizierer muss dieselbe Pfad-Normalisierung nutzen wie die verifizierte Operation
+
+**Muster:** Neues Renaming-Logging sollte nach jedem Rename verifizieren, ob die Datei
+wirklich unter dem Zielnamen liegt. `verifyRename` machte statSync/readdirSync auf den
+ROHEN Pfaden — der echte Rename lief aber über `toWindowsLongPathIfNeeded` (\?\-Prefix
+ab >=248 Zeichen). Bei langen Scene-Release-Pfaden (genau das, was die App routinemäßig
+umbenennt) scheiterten die rohen fs-Calls → falsches „Ziel nicht gefunden" UND — schlimmer —
+die Quell-Prüfung scheiterte ebenfalls → `sourceGone` fälschlich true → **falsches „OK"**,
+das einen halb-fertigen Verschiebevorgang maskiert. Der Diagnose-Log hätte genau die
+schwersten Fälle vergiftet. (Adversarialer Review-Workflow fand es, Confidence 0.8.)
+
+**Regel:** Wenn Code eine Operation VERIFIZIERT, muss er exakt dieselbe Pfad-/Encoding-/
+Normalisierung verwenden wie die Operation selbst (hier: \?\-Long-Path-Prefix). Sonst
+mis-reportet der Verifizierer still — und am verlässlichsten bei den Edge-Cases, die man
+eigentlich fangen wollte. Ein falsches OK in einem Diagnose-Log ist schlimmer als ein
+falsches ERROR. Zusatz: readdir-Fehler darf nicht zu „Schreibweise ok" degradieren
+(stilles False-OK) → eigenes WARN-Level „nicht verifizierbar".
+
+**Meta:** Bei einem Feature, dessen ganzer Zweck Beobachtbarkeit/Verifikation ist, lohnt
+ein adversarialer Review mit Fokus „würde die Verifikation auf der ECHTEN Last (lange
+Pfade, case-insensitive FS, EXDEV) korrekt urteilen?" — nicht nur „kompiliert + Happy-Path-Test".