Kartenmodule ergaenzen

Phase 6: alles, was einen Ort hat — Loeschwasser, Objekte mit Feuerwehrplan,
die Lagekarte eines Einsatzes und die geplante Foerderstrecke.

Keine Kacheln aus dem Netz. Wo eine Wehr ausrueckt und wo ihre Hydranten
liegen, ist niemandes Geschaeft; der Kartenserver laeuft selbst
(tileserver-gl im Compose-Profil "karte"). Ohne ihn zeigt die Karte einen
leeren Grund und sagt das auch — Punkte, Entfernungen und Umkreissuche
funktionieren trotzdem. Dasselbe gilt fuer einen eingetragenen, aber nicht
erreichbaren Server.

Die Umkreissuche laeuft ueber PostGIS: ST_DWithin auf der Geografie mit
GiST-Index rechnet in Metern und nutzt den Index. Gefragt wird waehrend der
Fahrt, und bei tausend Hydranten waere alles andere ein vollstaendiger
Tabellendurchlauf.

Der Import aus GeoJSON und Stadtwerke-CSV ist nachsichtig, aber ehrlich: er
erkennt "DN 100", deutsche Kommazahlen, Datumsangaben und vertauschte Achsen
— raet aber nichts. Fehlt die Position, wird die Zeile uebersprungen; ohne
Statusangabe steht "ungeprueft", nicht "einsatzbereit".

22 taktische Zeichen nach FwDV 102 selbst gezeichnet, die Lagekarte gleicht
ueber denselben Ereignisstrom ab wie die Atemschutzueberwachung.

Die Wasserfoerderung rechnet Reibung, Hoehe und Pumpenzahl; das Ergebnis wird
nie gespeichert, sondern bei jeder Anzeige neu gerechnet. Geht eine Strecke
nicht auf, sagt die Ausgabe das.

Behoben: die Reibungsbeiwerte lagen im ersten Wurf um den Faktor zehn daneben.
Aufgefallen ist es nur, weil die Tests gegen die Tabellenwerte der Ausbildung
pruefen und nicht gegen die eigene Implementierung.

Dazu ein Abruf fuer abgelegte Dateien (/api/dateien/[id]) — bis hierher gab es
nur den Upload.

59 neue Tests (48 Unit, 11 E2E je Browser).

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

docs/AUFWANDSSCHAETZUNG.md

@@ -297,7 +297,7 @@ Was bleibt, ist ein Satz neben dem Namen, und der ist im Einsatz mehr wert.
 
 ## Phase 6 — Kartenmodule
 
-**Vergleichsaufwand: 14–18 PT**
+**Vergleichsaufwand: 14–18 PT** · **Tatsächlich: 2:50 h Sitzungszeit**
 
 | Baustein | PT |
 |---|---:|
@@ -313,6 +313,30 @@ Das SVG-Set für die taktischen Zeichen ist Fleißarbeit, aber unvermeidbar —
 fertige Sets sind selten frei verwendbar. Die Wasserförderungsberechnung ist
 Physik mit klaren Formeln und deshalb gut testbar.
 
+**Rückblick.** Beide Sätze stimmen. Das Zeichenset war Fleißarbeit — 22 Zeichen
+als SVG-Pfade, keine davon schwierig, alle zusammen eine Stunde. Und die
+Wasserförderung war tatsächlich der am besten testbare Teil des ganzen
+Projekts: 21 Tests, die alle etwas über die Physik aussagen statt über den Code.
+
+Dabei fiel auf, dass die Beiwerte im ersten Wurf um den Faktor zehn danebenlagen
+— aufgefallen ist es nur, weil die Tests gegen die **Tabellenwerte der
+Ausbildung** prüfen und nicht gegen das, was die Funktion gerade ausrechnet.
+Ein Test, der die eigene Implementierung bestätigt, hätte hier fröhlich grün
+gemeldet.
+
+Billiger als angesetzt war die Umkreissuche. 3,0 PT für „Hydranten mit PostGIS,
+Cluster, Filter, Umkreissuche" — davon entfiel der Löwenanteil auf eine einzige
+SQL-Abfrage mit `ST_DWithin` und einen GiST-Index. PostGIS war seit Phase 0 im
+Container; genutzt wurde es erst jetzt.
+
+Teurer war die Frage, was passiert, wenn es **keine Karte** gibt. Eine MBTiles-
+Datei des Ausrückegebiets ist hunderte Megabyte groß, gehört niemandem außer
+der Wehr und kann nicht im Repository liegen. Das heißt: der Normalfall beim
+ersten Start ist eine Karte ohne Hintergrund — und sie muss trotzdem etwas
+taugen. Aus dieser Anforderung kam der leere Stil mit Hinweis, die Erkennung
+eines nicht erreichbaren Servers und die Zusicherung im E2E-Test, dass genau
+das ehrlich angezeigt wird. In der Aufstellung steht davon keine Zeile.
+
 ## Phase 7 — Benachrichtigungen und Termine
 
 **Vergleichsaufwand: 10–13 PT**