Aufraeumarbeiten: ESLint, DOM-Verschachtelung, eigene Testwehr

ESLint hatte keine Konfiguration — das Skript "npm run lint" pruefte nichts.
Jetzt Flat Config ohne Formatierungsregeln, dafuer mit den Regeln, die die
Fehler dieses Projekts gemeldet haetten. Er hat gleich zwei gefunden, die
niemand gesucht hatte.

Das Badge rendert ein span statt eines div. Damit ist die Meldung
"div cannot be a descendant of p" weg, die seit Phase 3 auf der Einsatzseite
stand — sie ist der klassische Ausloeser fuer einen Hydration-Fehler.

Die E2E-Tests laufen gegen eine eigene Wehr. Nach fuenf Phasen standen in der
Beispielwehr 120 Atemschutz-Ueberwachungen statt einer und 115 Geraete statt
45; bei jedem Lauf aenderten sich alle Bildschirmfotos. Der Bestand ist einmal
zurueckgesetzt, npm run db:test-reset baut die Testwehr neu auf.

Behoben nebenbei:
- Die Fehlerflaeche der Karte konnte nie etwas anzeigen.
- Zwei useMemo der Lagekarte rechneten bei jedem Rendern neu.
- tests/e2e war vom Typecheck ausgenommen und liess einen doppelt
  deklarierten Bezeichner durch.

Closes #10
Closes #11
Closes #12

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

tests/e2e/wehr.ts

@@ -0,0 +1,71 @@
+import { expect, type Page } from "@playwright/test";
+
+/**
+ * Die Wehr, gegen die getestet wird.
+ *
+ * **Eine eigene, nicht die Beispielwehr.** Bis Phase 8 schrieben die Tests in
+ * `ff-musterhausen` — also in genau den Bestand, den die Anleitung zeigt und
+ * aus dem die Bildschirmfotos entstehen. Nach fünf Phasen standen dort
+ * 94 Atemschutz-Überwachungen statt einer, 49 Geräte statt 45 und Termine mit
+ * Namen wie „E2E-Absage-m1x8kq". Zweimal fielen Tests aus, weil ein gesuchter
+ * Eintrag von Seite 1 gerutscht war, und bei jedem Lauf unterschieden sich
+ * alle 72 Bildschirmfotos.
+ *
+ * Vor dem Lauf:
+ *
+ *     npm run db:test-reset
+ *
+ * Das legt die Testwehr neu an — vollständig, mit denselben Beispieldaten wie
+ * die Musterwehr, aber unter eigener Kennung. Die Beispielwehr wird dabei
+ * nicht angefasst.
+ */
+
+export const ADMIN_EMAIL = process.env.E2E_ADMIN_EMAIL ?? "e2e@teststelle.de";
+export const ADMIN_PASSWORT = process.env.E2E_ADMIN_PASSWORT ?? "Feuerwehr2026";
+
+/** Der Name, der nach der Anmeldung auf der Uebersicht steht. */
+export const WEHR_NAME = process.env.E2E_NAME ?? "Freiwillige Feuerwehr Teststelle";
+
+/**
+ * Die Kennung der Testwehr.
+ *
+ * Wird von der Terminal-Einrichtung gebraucht: das Wandtablet merkt sich, zu
+ * welcher Wehr es gehoert, und schreibt Maengel, Fahrten und Anwesenheiten
+ * genau dorthin. Bis Phase 8 stand hier fest "ff-musterhausen" — das war der
+ * letzte Weg, ueber den die Tests in die Beispielwehr geschrieben haben.
+ */
+export const WEHR_SLUG = process.env.E2E_SLUG ?? "ff-teststelle";
+
+/**
+ * Als Administrator der Testwehr anmelden.
+ *
+ * Stand bis Phase 8 achtmal wortgleich in acht Dateien. Dass die Zugangsdaten
+ * damit an neun Stellen zu ändern waren, war der eigentliche Grund, warum die
+ * Umstellung auf einen eigenen Mandanten so lange liegen geblieben ist.
+ */
+export async function anmelden(page: Page): Promise<void> {
+  await page.goto("/anmelden");
+  await page.getByLabel("E-Mail-Adresse").fill(ADMIN_EMAIL);
+  await page.getByLabel("Passwort").fill(ADMIN_PASSWORT);
+  await page.getByRole("button", { name: "Anmelden" }).click();
+
+  // Mit Begruendung statt mit einem nackten Zeitlimit: fehlt die Testwehr,
+  // schlagen sonst zweihundert Tests mit „Timeout" fehl, und niemand sieht
+  // die eine Ursache dahinter.
+  await expect(
+    page,
+    `Anmeldung als ${ADMIN_EMAIL} fehlgeschlagen. Steht die Testwehr? ` +
+      "Vor dem Lauf einmal: npm run db:test-reset",
+  ).toHaveURL("/");
+}
+
+/**
+ * Ein eindeutiger Name je Lauf.
+ *
+ * Auch mit eigenem Mandanten bleibt er sinnvoll: zwei Arbeiter laufen
+ * parallel, und zwei Termine namens „Testtermin" wären nicht zu unterscheiden.
+ */
+export function eigenerName(zweck: string): string {
+  return `E2E-${zweck}-${Date.now().toString(36)}`;
+}
+