fix(PROJ-79): next lint kaputt seit Next-16-Upgrade repariert + 30 Findings gefixt

npm run lint rief next lint auf, das es in Next.js 16 nicht mehr gibt —
seit dem Next-16-Upgrade lief effektiv gar kein Lint mehr. Umgestellt auf
eslint . mit Flat-Config (eslint.config.mjs statt .eslintrc.json). Der
dadurch wieder sichtbare Lint-Lauf zeigte 30 Findings (25 Fehler,
5 Warnungen), alle gefixt:

- 19x react-hooks/set-state-in-effect: Loading-States wo möglich als
  echte Ableitung statt eigenem Effect-State (use-mobile.tsx komplett auf
  useSyncExternalStore umgebaut), sonst async-Wrapper mit Cancel-Guard um
  bestehende Loader — Timing/Ladeanzeige unverändert.
- react-hooks/refs (useSearch.ts): Ref-Schreibzugriff aus dem Render in
  einen Effect verschoben.
- 4x no-html-link-for-pages: <a href> durch next/link ersetzt in
  admin/login, forgot-password, signup.
- Rest (exhaustive-deps, no-img-element, unused disable) einzeln gefixt.
- 4 bewusst belassene disable-Kommentare mit Begründung (shadcn/ui-Datei,
  QR-Code-data-URL, Full-Reload nach Auth laut Projektregel).

eslint-Major-Upgrade auf 10 selbst bleibt blockiert: eslint-plugin-react/
jsx-a11y/import unterstützen ESLint 10 in ihrer aktuellen Latest-Version
noch nicht (Crash beim Laden), siehe Feature-Spec PROJ-79.

Verifiziert auf 132 (Build-Sandbox, kein Live-Deploy): npm ci/tsc/lint/
build grün, 8 Kern-Routen per Standalone-Server auf HTTP 200 geprüft.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019j28kGcaJAhBnrYX34hGdt

features/PROJ-75-db-performance-audit.md

@@ -1,7 +1,7 @@
 ---
 id: PROJ-75
 title: DB-Performance-Audit (Query-Index-Nutzung, Fan-out, pgxpool-Tuning)
-status: In Review
+status: Deployed
 created: 2026-08-05
 ---
 
@@ -95,6 +95,12 @@ Seq Scan → Index Scan bestätigt, Ausführungszeit von 13.3ms auf 0.086ms
 gesunken (~150x). Migration erfolgreich, nur auf 132 angewendet — 131 bewusst
 nicht angefasst.
 
+Deployed auf 131 (Produktiv) am 2026-08-05. Der Index `idx_emails_unindexed`
+wurde beim Backend-Start automatisch über `initSchema` (idempotent via
+`CREATE INDEX IF NOT EXISTS`) angelegt — verifiziert per
+`pg_indexes`-Abfrage auf 131, kein manueller SQL-Schritt nötig. Startup-Log
+lief ohne Fehler durch, keine Auffälligkeiten trotz größerer Produktivtabelle.
+
 - `ListExpiredMails` (mark_deletion.go, `WHERE retain_until IS NOT NULL AND
   retain_until < NOW() [AND tenant_id = $N] ORDER BY retain_until ASC LIMIT
   500`): **Index Scan bestätigt, keine Änderung nötig.** Nutzt bereits