feat: add per-provider account priority rules

PROJECT_MEMORY.md

@@ -8,10 +8,13 @@ Diese Datei hält den verifizierten technischen Arbeitsstand fest. Sie enthält
 
 ## Zuletzt verifizierter Stand
 
+- 6. September 2026, Account-Reihenfolge implementiert, noch nicht veröffentlicht: Unter Einstellungen → Accounts → Verwendungsregeln lassen sich Real-Debrid, Mega-Debrid API/Web und Debrid-Link aufklappen. Pro Provider Wahl zwischen unveränderter automatischer Verteilung (Standard) und fester Priorität. Accounts mit Identität, Modus und Status werden per Pfeilen oder Drag-and-drop innerhalb desselben Providers geordnet; Änderungen werden mit „Einstellungen speichern“ übernommen. Provider ohne Mehrfachaccount-Unterstützung behalten ihre bestehende einzelne Zugangskonfiguration.
+- `accountUsageRules` speichert Modus und Account-IDs getrennt von Zugangsdaten. Normalisierung entfernt fremde/gelöschte IDs, dedupliziert und hängt neue Accounts an. Account-Ersetzen/Passwortwechsel erhält die Prioritätsposition auch bei wechselnder ID; Löschen entfernt Referenzen. Renderer-Payloads werden verschachtelt validiert. Einstellungen und verschlüsselte Backups übernehmen die Regeln; bestehende Installationen bleiben automatisch.
+- Feste Priorität wirkt in der tatsächlichen Link-Auflösung der drei Provider-Engines, nicht nur in der Ansicht. Disabled-/Tageslimit-/Cooldown-/Hosterprüfungen und Provider-Fallback bleiben erhalten. Nach Cooldown-Ende hat der bevorzugte Account für neue Auflösungen wieder Vorrang. Bei Mega-Debrid belegt jede Prioritätsauflösung höchstens einen Umwandlungsplatz pro Account: belegte Accounts werden zugunsten des nächsten freien übersprungen, Vollbelegung wartet abbrechbar und prüft Sperren erneut. Real-Debrid und Debrid-Link behalten ihre vorhandenen Parallelitätsgrenzen; Account-Kapazitätsfehler werden weiterhin als Sperr-/Fallbackgrund behandelt. Laufende Downloads mit bereits aufgelösten URLs werden nicht umgeschaltet.
+- Prüfung des Account-Modus: neue Tests für alle vier Routen einschließlich gemischter Real-Debrid API/Web-Priorität, Cooldown-Rückkehr, Disabled/Tageslimit, Provider-Fallback an/aus, Mega-Parallelplätze samt Warten/Abbrechen, Account-Ersetzen/Anlegen/Löschen, Neustart und verschlüsselten Backup-Roundtrip. Alle 124 bisherigen Debrid-Tests unverändert erfolgreich. `tests/visual/account-priority.html` prüft die echte App mit ausschließlich Testdaten: Aufklappen, Standardmodus, Moduswechsel, Pfeile, Drag-and-drop, Ablehnung fremder Provider-Drops, Speichern und horizontale Grenzen. Dark-/Light-Screenshots geprüft. TypeScript, Self-Check und beide Builds erfolgreich. Finaler Clientlauf: 2.774 Tests bestanden, vier optionale Tests übersprungen; separat 22 Release-Metadatentests bestanden, zwei bekannte Windows-Symlink-Fixtures ausgenommen (insgesamt 2.796 erfolgreiche Client-Tests). Zusätzlich alle 16 Backup-API-Tests erfolgreich. Kein Release, keine produktive Installation und kein Serverneustart.
 - 6. September 2026, noch nicht veröffentlicht: `switchToCollectorOnClipboard` macht den automatischen Tabwechsel bei erkannten Zwischenablage-Links optional. Standard und Migration vorhandener Konfigurationen ohne Feld sind `false`; nur explizites `true` aktiviert ihn. Schalter unter Einstellungen → Allgemein → Download-Verhalten, deutsch/englisch übersetzt. Zwischenablage-Import sammelt und speichert weiterhin im Hintergrund und verändert bei ausgeschalteter Option weder Tab noch Linksammlerfilter. Manuelles Einfügen, Drag-and-drop und DLC-Import behalten ihre bisherige Navigation. Die Entscheidung liest nach der asynchronen Vorbereitung die aktuell bestätigte Einstellung, damit Ausschalten während eines Imports berücksichtigt wird.
 - Verifiziert: TypeScript, Main-/Renderer-Build und 522 gezielte Tests für Einstellungen, Persistenz/Migration, Renderer-Validierung, Übersetzung, Collector und Backups. Isolierte Electron-Browserprobe `tests/visual/collector-navigation.html` verwendet ausschließlich Testdaten und bestätigt Hintergrundimporte aus Downloads/Einstellungen, Opt-in sowie Opt-out während eines laufenden Imports; alle vier Pakete bleiben gespeichert. Keine produktive Konfiguration geändert, kein Serverneustart und kein neues Release.
-- Planungsauftrag Account-Reihenfolge (noch nicht implementieren): Unter Verwendungsregeln die Provider aufklappbar machen, darin nur deren Accounts mit Name, API/Web-Modus, Prioritätsnummer und aktuellem Status anzeigen; Reihenfolge per Drag-and-drop und Pfeiltasten ändern. Pro Provider Wahl zwischen bisheriger automatischer Verteilung (Migrationsstandard) und fester Priorität. Feste Priorität nutzt für neue Auflösungen den ersten tatsächlich nutzbaren Account; deaktivierte Accounts, Tageslimits, passende Cooldowns und ausgeschöpfte Account-Kapazität werden übersprungen. Nach Erholung hat Account 1 wieder Vorrang; laufende Downloads werden nicht umgeschaltet. Erst nach Ausschöpfen der Accounts greift die bestehende Provider-Fallbackregel. Link-/providerweite Fehler dürfen keine sinnlose Rotation durch alle Accounts auslösen.
-- Technische Basis des Account-Plans: `AccountWorkspace.tsx` rendert aktuell nur Provider-Zeilen. Debrid-Link iteriert in `debrid.ts` bereits in Key-Reihenfolge mit Disabled-/Limit-/Cooldown-Prüfungen; Real-Debrid verwendet geringste In-flight-Auslastung plus Sticky-/Rotationszustand, Mega-Debrid Cursor-Reihenfolge plus In-flight-Sortierung. Deshalb ist eine reine UI-Umsortierung unzureichend. Umsetzung in drei überprüfbaren Schritten: (1) separates Prioritätsmodell pro Provider mit stabilen Account-IDs, Normalisierung, Speichern/Backup sowie Referenzpflege beim Ersetzen/Löschen und Anhängen neuer Accounts; (2) aufklappbare Bedienung und Moduswahl ohne Geheimnisse; (3) priorisierte Auswahl in den drei Engines unter Erhalt von Hoster-/Account-Limits und Reservierungen. Tests müssen 1→2→3 bei Sperren, Rückkehr zu 1 nach Cooldown, Parallelität, Provider-Fallback an/aus, Neustart/Import, Accountänderungen und unveränderten Automatikmodus abdecken. Mittlerer Funktionsumfang, kein bloßer Listenumbau; Freigabe der konkreten Semantik vor Implementierung.
+- Der ursprünglich nur geplante Account-Prioritätsmodus wurde anschließend mit „Mach das Chef“ zur Umsetzung freigegeben; aktueller Implementierungs- und Prüfstand siehe oben. Die unveränderte Automatik bleibt der Migrationsstandard.
 - Release `v2.0.89` nach ausdrücklichem „release!“ auf GitHub und Forgejo veröffentlicht: Drei-Klick-Verfügbarkeitssortierung mit Part-Anzahl bei Gleichstand und korrigierte Hot-Dev-Startskripte. TypeScript, Node-Self-Check, Main-/Renderer-Build und 16 Backup-API-Tests erfolgreich. Finaler Clientlauf mit vier Workern: 2.748 Tests erfolgreich, vier optionale JVM-Tests übersprungen; separat 22 Release-Metadatentests erfolgreich, zwei bekannte Windows-Symlink-Fixtures ausgenommen (insgesamt 2.770 erfolgreiche Client-Tests). Ein bestehender Updater-Timeout im ersten stark parallelen Lauf bestand isoliert und im vollständigen Wiederholungslauf.
 - Veröffentlichungsprüfung `v2.0.89`: Tag auf beiden Remotes exakt `e18dfa12044e775ff30739029f07f30f9931fced`; beide Plattformen führen denselben Titel und Tag als neuesten stabilen Release, GitHub-Text Englisch und Forgejo-Text Deutsch. Alle zwölf öffentlichen Assets erneut heruntergeladen und Größe sowie SHA-256 mit den lokalen Originalen verglichen. Beide `latest.yml` bestätigen Version und Installer-SHA-512. Setup-SHA-256 `830856d02b41a37a938552b1d828062617fb7feb131791f1eaed1bc9e34c644c`, Portable-SHA-256 `97f04e83397866da50b7750f55f517d5872d52280432ac348251b0088677af43`. Installer-/Portable-Inhalte mit `verify_public_release.mjs --verify-archives` geprüft; Quellarchiv mit 7-Zip geprüft, entspricht dem Tag-Commit. Lokale Originale unter `release/staging-v2.0.89`. Keine produktive Installation und kein Serverneustart.
 - Availability-Sortierung nach `v2.0.88`: Klickfolge online/viele Parts zuerst → offline/wenige Parts zuerst → ursprüngliche Reihenfolge ohne aktiven Sortierpfeil. Online-/Offline-Anteile bleiben vorrangig; Part-Anzahl entscheidet nur bei identischer Verfügbarkeit. Neue Pakete bleiben beim Ausschalten hinten erhalten, gelöschte werden nicht wieder eingefügt. Wechsel auf eine andere Sortierspalte setzt den Availability-Zyklus zurück. Bestehender Pending-Snapshot-Schutz und sofortiger Sortierwechsel bleiben erhalten. TypeScript und gezielte Sortier-/Ansichtstests erfolgreich; isolierte Electron-Browserprobe mit Testdaten prüft zwei vollständige Zyklen samt verzögerten Snapshots, Sortierindikatoren und DOM-Reihenfolge ohne falsche Zwischenstände. Kein neues Release.