test(260924-m4n): flackernden Marktplatz-Test entschaerfen, act-Warnungen der Proxmox-Kachel weg

- tenant-selector: Komponenten statisch statt im Test dynamisch importiert
  (Laden zaehlte in die 5-s-Frist des ersten Tests), SUPER_ADMIN/ADMIN in
  zwei it aufgetrennt
- marketplace/marketplace-filters: gleiche Umstellung; userEvent an die
  falsche Uhr gekoppelt statt auf shouldAdvanceTime zu warten
- proxmox-widget: Rendern wartet das erste Laden in act() ab (81 Warnungen weg)
- Todo 2026-09-23 nach completed/

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

.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md

@@ -1,51 +0,0 @@
----
-created: 2026-09-23
-title: Flackernder Test "TenantContextSelector" — Zeitüberschreitung bei 5 s, hat die Freigabe 1.3.1 blockiert
-area: apps/web
-severity: flake
-trigger: sobald wieder an apps/web gearbeitet wird — spätestens vor der nächsten Freigabe, weil der Fall dort teuer ist.
-relates_to: Freigabe v1.3.1 (CI-Lauf 418, Job 1262)
----
-
-## Was passiert ist
-
-Beim Freigeben von 1.3.1 lösen drei Pipelines gleichzeitig aus (`main`, Zweig
-`live`, Tag `v1.3.1`). Auf dem Tag-Lauf fiel der Test
-
-```
-src/app/(portal)/marketplace/tenant-selector.test.tsx
-  > TenantContextSelector > renders tenant options for SUPER_ADMIN; renders nothing for ADMIN
-```
-
-mit `Error: Test timed out in 5000ms` aus. **Derselbe Commit** (`ad004b28`) war
-im selben Zeitraum auf `main` (Lauf 1025) und auf `live` (Lauf 1026) grün — es
-ist also kein Fehler im Code, sondern der Läufer war mit drei parallelen
-Pipelines ausgelastet und der Test lief in sein 5-Sekunden-Limit.
-
-## Warum das teuer war
-
-Der Abbild-Bau hängt am Test-Job. Rot heißt: **„Build & Publish Images" und
-„Desktop-Pakete bauen" wurden übersprungen** — die Freigabe war damit getaggt,
-aber nicht gebaut. Kein `live`-Abbild, kein Gitea-Release, keine
-Desktop-Pakete. Erst ein Neustart des Laufs (Gitea-API,
-`POST /actions/runs/418/rerun`) hat alles nachgeholt.
-
-Das trifft **jede** Freigabe, weil jede Freigabe drei gleichzeitige Läufe
-auslöst. Der Fall wiederholt sich also, nicht zufällig.
-
-## Was zu tun ist
-
-1. Den Test ansehen: warum braucht er überhaupt nahe 5 s? Verdacht ist ein
-   `waitFor` auf etwas, das erst nach einem Datenabruf erscheint, oder zwei
-   Fälle (SUPER_ADMIN und ADMIN) in EINEM `it`, das dadurch doppelt so lange
-   läuft — der Testname nennt beide Fälle in einem Satz.
-2. Entweder auftrennen (zwei `it`-Blöcke) oder die Wartezeit gezielt erhöhen.
-   Ein globales Hochsetzen von `testTimeout` versteckt nur, dass hier etwas
-   langsam ist.
-3. Prüfen, ob weitere Tests nahe am Limit liegen — die Läuferlast bleibt ja.
-
-## Nicht die Lösung
-
-Die drei parallelen Pipelines abschalten: der Lauf auf `main` und der auf dem
-Tag prüfen unterschiedliche Dinge, und der `live`-Lauf ist die Absicherung,
-dass der Zweig für sich genommen grün ist.