Ladegrenzen für jede Route, Turbopack im Entwicklungsserver

Gemessen statt vermutet: die Datenschicht war nie das Problem. resolvePermissions
unter 1 ms, loadDashboard 11 ms, searchCases 5 ms, die Abteilungsabfragen 3–4 ms.

Die Sekunden kamen aus zwei Ecken.

**Fehlende Ladegrenzen.** Den meisten Routen fehlte loading.tsx - unter anderem
der Übersicht, der Suche und dem gesamten Adminbereich. Ohne diese Datei hat
der Router keine Grenze, wartet stumm auf die fertige Serverantwort, und bis
dahin steht die alte Seite: man klickt, und scheinbar passiert nichts. Neunzehn
Skelette nachgetragen, jede Route hat jetzt eine.

Dazu quittiert der geklickte Link den Klick selbst, mit einem ruhig
pulsierenden Punkt statt eines Kreisels. Regel 5 verbietet den
Blockade-Spinner, der Inhalt ersetzt; eine Quittung im Link ersetzt nichts, und
die eigentliche Antwort auf das Warten bleibt das Skelett.

**Webpack.** Der Entwicklungsserver übersetzte jede Route beim ersten Aufruf
neu: 8 s für die Übersicht, 2,8 s für die Fallliste. Mit Turbopack sind es
0,43 s beim ersten Aufruf und 0,1 s danach. Nur pnpm dev, der Produktionsbau
bleibt unverändert. Gegengeprüft, dass die Anmeldeseite mit CSS und ohne
Fehler im Log rendert.

Nebenbei die eine Abfrage, die schlecht skalierte: die Übersicht zählte
ungelesene Nachrichten mit einer Abfrage je Ort - bei hundert Akten hundert
Hin- und Rückwege. Jetzt ein einziges groupBy mit der Lesemarke im ODER-Zweig
des jeweiligen Ortes. Ein Test prüft, was dabei leicht verrutscht: die Marke
gilt je Ort, und eigene Nachrichten zählen nie mit.

web/lib/dashboard/load.ts

@@ -147,25 +147,35 @@ async function ungeleseneChats(p: EffectivePermissions): Promise<UnreadChat[]> {
   ]
   if (orte.length === 0) return []
 
-  const zaehler = await Promise.all(
-    orte.map(async (ort) => {
-      const seit = markeVon.get(`${ort.scopeType}:${ort.scopeId}`)
-      const count = await db.chatMessage.count({
-        where: {
-          AND: [
-            visibleMessageWhere(p),
-            ort.wo,
-            { withdrawnAt: null },
-            { authorId: { not: p.userId } },
-            ...(seit ? [{ createdAt: { gt: seit } }] : []),
-          ],
-        },
-      })
-      return { ort, count }
-    }),
+  // **Eine** Abfrage statt einer je Ort. Vorher war das ein `count` pro Akte
+  // und pro Personalakte — bei hundert Orten hundert Hin- und Rückwege zur
+  // Datenbank, jeder für sich schnell und in der Summe die langsamste Stelle
+  // der Übersicht. Die Lesemarke steckt als Bedingung im ODER-Zweig des
+  // jeweiligen Ortes, gezählt wird über `groupBy`.
+  const zweige = orte.map((ort) => {
+    const seit = markeVon.get(`${ort.scopeType}:${ort.scopeId}`)
+    return seit ? { AND: [ort.wo, { createdAt: { gt: seit } }] } : ort.wo
+  })
+
+  const gruppen = await db.chatMessage.groupBy({
+    by: ['caseId', 'personnelFileId'],
+    where: {
+      AND: [
+        visibleMessageWhere(p),
+        { withdrawnAt: null },
+        { authorId: { not: p.userId } },
+        { OR: zweige },
+      ],
+    },
+    _count: { _all: true },
+  })
+
+  const anzahlVon = new Map(
+    gruppen.map((gruppe) => [gruppe.caseId ?? gruppe.personnelFileId ?? '', gruppe._count._all]),
   )
 
-  return zaehler
+  return orte
+    .map((ort) => ({ ort, count: anzahlVon.get(ort.scopeId) ?? 0 }))
     .filter((eintrag) => eintrag.count > 0)
     .sort((a, b) => b.count - a.count)
     .slice(0, 10)