docs(lessons): byse suspect-reject Erkenntnisse + GitHub-Mirror-Prozedur (v3.3.66)

tasks/lessons.md

@@ -62,3 +62,21 @@
 - file/list → 90.548 Dateien; Uploads landen server-seitig INTERMITTIEREND (viele Burn-Notice-Folgen genau im "Fehler"-Zeitfenster vorhanden). Das leere Formular ist also nicht "immer kaputt", sondern manchmal — der Web-Form-Registrierungs-Callback (fs-public.intconnect.net) timeoutet sporadisch.
 **Konsequenz:** API-Weg (result[0].filecode inline) umgeht den failenden Callback → richtiger Fix. file/list-Recovery ist NICHT tote Last (Dateien erscheinen ja) — aber bei 90k-Accounts MUSS man sort=created&order=desc erzwingen, sonst ist die frische Datei nicht auf Seite 1.
 **Regel:** Bei "geht manchmal/manchmal nicht" + Hoster mit offizieller API: erst per read-only API-Call (account/info, file/list) gegen den ECHTEN Account verifizieren statt am Client weiterzuraten. Das beendet Spekulations-Schleifen.
+
+## 2026-06-11 — Rotation erreichte Account 4 nie (v3.3.66)
+- **Hoster-Fehlertexte lügen tier-abhängig:** byse "Not video file format" war für valide
+  MKVs >2,7GB ein Account-Größen-Limit (Beweis: sauberer Size-Split 1158 OK ≤2,62GB vs.
+  6 rejected ≥2,81GB auf demselben Account). Eine "file rejected → Rotation sinnlos"-
+  Klassifizierung darf nie nur auf dem Servertext beruhen, wenn die eigene File-Probe
+  das Gegenteil beweist (probe sagt matroska → Verdikt suspekt → andere Accounts testen).
+- **Optimierungen gegen dokumentierte Rescue-Pfade diffen:** 1d116ac ("skip 30s poll on
+  explicit reject") hat den Poll exakt für den Fall getötet, dessen Kommentar 5 Zeilen
+  darüber stand. Vor jedem Guard um einen bestehenden Rettungspfad: dessen Kommentar/Tests
+  lesen, sonst zementiert der neue Test die Regression (Test behauptete das Skip-Verhalten).
+- **Jeder Retry-Pfad braucht dieselbe Fehler-Klassifizierung + dasselbe Logging wie der
+  Hauptpfad:** Der Rotations-Inner-Loop hatte weder upload-failure-Logs (Account 2 starb
+  unsichtbar — Diagnose unmöglich) noch fileRejected-Fast-Breaks (4× 2,7GB-Re-Upload, dann
+  Blacklist eines gesunden Accounts).
+- **GitHub-Mirror-Falle:** Mirror hat separate bereinigte Historie (ohne electron-config.json).
+  `gh release create` pusht Tags aus der LOKALEN Historie → Credentials-Leak. Prozedur:
+  Cherry-Pick-Worktree auf github/master, Tag auf Mirror-Commit. (Memory: feedback_github_mirror_separate_history)