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/completed/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md

@@ -49,3 +49,17 @@ auslöst. Der Fall wiederholt sich also, nicht zufällig.
 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.
+
+## Erledigt in quick-260924-m4n (24.09.2026)
+
+- Ursache: `TenantContextSelector` und die Marktplatzseite wurden per
+  `await import(...)` INNERHALB der Tests geladen. Das Laden und Umwandeln der
+  Module zählte damit in die 5-s-Frist des ersten Tests — unter Läuferlast
+  (drei Pipelines je Freigabe) reicht das, um die Frist zu reißen.
+- Behoben: statische Importe (vi.mock wird darüber gehoben), der Doppelfall
+  SUPER_ADMIN/ADMIN in zwei `it` aufgetrennt (der ADMIN-Fall prüft zusätzlich,
+  dass kein Abruf passiert). Dieselbe Umstellung in `marketplace.test.tsx` und
+  `marketplace-filters.test.tsx`; dort ist userEvent zusätzlich an die falsche
+  Uhr gekoppelt (`advanceTimers`). Kein globales `testTimeout`.
+- Messung (ganze Web-Suite, lokal und auf 2 Kerne gedrosselt): kein Test über
+  2 s; der langsamste lag gedrosselt bei rund 1,3 s.