feat: ein Name statt zwei, und PUBLIC_URL ist nur noch der Ursprung

fivecdn.d4rkst3r.de und fivemanage.d4rkst3r.de fallen weg -- wir betreiben
kein Fivemanage, also tragen unsere Adressen auch nicht dessen Namen.
Dashboard und API liegen an der Wurzel, die Dateien unter /f/.

Der Ein-Namen-Betrieb war bis jetzt nicht ausdrueckbar. Der Kommentar in
config.ts versprach "leer lassen, wenn alles unter einem Namen laufen
soll", aber optional() faellt bei leerem Wert auf den Host aus PUBLIC_URL
zurueck -- und dann gilt JEDE Anfrage als Anfrage an den Dateiwirt: kein
Dashboard, keine API, /health gibt 404 und die Anmeldung 405 "hier gibt
es nur Dateien". Nichts ist kaputt, und niemand kommt darauf. Deshalb ist
der Ein-Namen-Betrieb jetzt der Standard und der zweite Name die Ansage.

PUBLIC_URL ist nur noch der Ursprung; das /f haengt der Dienst selbst an.
Wer es mitschriebe, bekaeme Adressen mit /f/f/, und das faellt erst auf,
wenn das erste Bild fehlt. Praefix und Route haengen jetzt an derselben
Stelle (config.filePrefix), damit die zurueckgegebene Adresse und die
Route, die sie ausliefert, nicht auseinanderlaufen koennen.

Beide Betriebsarten durchgemessen: mit einem Namen kommt
.../f/vehicles/adder.png zurueck und liefert die Datei; mit gesetztem
FILES_HOST kommt sie ohne Praefix, liegt unter dem Dateihost, ist am
Dashboard-Namen zusaetzlich unter /f/ erreichbar, und unter dem Dateihost
gibt es weiterhin keine API. Welche Betriebsart laeuft, sagt der Dienst
in der zweiten Startzeile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ROADMAP.md

@@ -27,16 +27,27 @@ kein zweiter Dienst, kein Passwort dazwischen, und eine Sicherung ist ein
 `cp -a` über ein Volume. Wenn daraus je Millionen Zeilen werden, wird
 `server/src/db.ts` ausgetauscht — die Aufrufer merken davon nichts.
 
-**Zwei Hostnamen, ein Prozess.**
+**Ein Name.** `fivecdn.d4rkst3r.de` und `fivemanage.d4rkst3r.de` fallen weg —
+wir betreiben kein Fivemanage, also tragen unsere Adressen auch nicht dessen
+Namen. Dashboard und API liegen an der Wurzel, die Dateien unter `/f/`:
 
-| | |
-|---|---|
-| `fivecdn.d4rkst3r.de` | nur Dateien. Kein Dashboard, keine API, nichts anzumelden |
-| `fivemanage.d4rkst3r.de` | Dashboard und API |
+```
+https://media.d4rkst3r.de/          Dashboard und API
+https://media.d4rkst3r.de/f/vehicles/adder.webp
+```
 
-Das hält die öffentliche Adresse frei von Angriffsfläche und die URLs hübsch:
-`https://fivecdn.d4rkst3r.de/vehicles/adder.webp`, ohne `/f/`-Präfix. Die
-Vorlage im Handy bleibt damit schlicht `{model}.webp`.
+Ein DNS-Eintrag, ein Host im Proxy. Aufgegeben ist damit eine Eigenschaft, die
+zwei Namen mitbrächten: die öffentliche Adresse trägt jetzt auch das
+Anmeldeformular.
+
+Zwei Namen kann der Dienst weiterhin — `FILES_HOST` setzen, dann gibt es unter
+diesem Namen ausschließlich Dateien und die URLs kommen ohne `/f/` aus. Beides
+ist gemessen. Der Wechsel ist billig: die Adressen stehen **nirgends in der
+Datenbank**, sie werden bei jeder Antwort aus `PUBLIC_URL` gebaut.
+
+**Der Pfad bleibt in beiden Fällen der Schlüssel.** `vehicles/adder.webp`
+bleibt `vehicles/adder.webp`, die Vorlage im Handy also `{model}.webp`. Nur der
+Teil davor ändert sich, und der steht in einer Variablen.
 
 **Der Pfad ist der Schlüssel.** `X-Path: vehicles/adder.webp` legt die Datei
 genau dort ab. Vorhersagbare URLs sind für das Fotostudio die ganze
@@ -100,13 +111,14 @@ cp server/.env.example server/.env
 npm --prefix server ci && npm --prefix server run dev
 ```
 
-> **Der Stolperstein beim lokalen Start:** ohne `FILES_HOST` nimmt der Dienst
-> den Host aus `PUBLIC_URL` — lokal also `localhost`. Dann gilt *jede* Anfrage
-> als Anfrage an den Dateiwirt, und dort gibt es absichtlich weder Dashboard
-> noch API: `/health` antwortet 404, die Anmeldung 405 „hier gibt es nur
-> Dateien". Nichts ist kaputt. In Produktion sind es zwei verschiedene Namen
-> und der Standard stimmt; lokal gehört ein Name hin, den niemand aufruft.
-> Steht samt Begründung in `server/.env.example`.
+> **Der Stolperstein, den es nicht mehr gibt.** Anfangs war der Standard für
+> `FILES_HOST` der Host aus `PUBLIC_URL`. Bei zwei Namen ist das richtig, bei
+> einem tödlich: dann galt *jede* Anfrage als Anfrage an den Dateiwirt,
+> `/health` gab 404 und die Anmeldung 405 „hier gibt es nur Dateien". Nichts
+> war kaputt, und niemand kommt darauf. Seit der Entscheidung für einen Namen
+> ist der Ein-Namen-Betrieb der Standard und der zweite Name die Ansage —
+> lokal läuft es damit ohne Sonderbehandlung. Welche Betriebsart gilt, sagt
+> der Dienst in der zweiten Startzeile.
 
 **Was der Test gefunden hat** — alles im Grundgerüst, alles repariert:
 
@@ -150,6 +162,20 @@ HEAD, Bereichsanfragen und 416 · unter dem Dateihost gibt es weder API noch
 
 Nicht getestet: Docker, das Dashboard (gibt es noch nicht), und echte Last.
 
+### ✅ Fertig — ein Name statt zwei
+
+`PUBLIC_URL` ist jetzt nur noch der Ursprung; das `/f` hängt der Dienst selbst
+an. Wer es mitschriebe, bekäme Adressen mit `/f/f/` — und das fiele erst auf,
+wenn das erste Bild fehlt. Prefix und Route werden deshalb an genau **einer**
+Stelle entschieden (`config.filePrefix`), damit die zurückgegebene Adresse und
+die Route, die sie ausliefert, nicht auseinanderlaufen können.
+
+Beide Betriebsarten sind durchgemessen: mit einem Namen kommt
+`…/f/vehicles/adder.png` zurück und liefert die Datei; mit gesetztem
+`FILES_HOST` kommt sie ohne Präfix, liegt unter dem Dateihost, ist am
+Dashboard-Namen zusätzlich unter `/f/` erreichbar, und unter dem Dateihost gibt
+es weiterhin keine API.
+
 ### ⬜ Als Nächstes
 
 **2 · Dockerfile und Compose.** Ein Abbild, das Server und gebaute Oberfläche