frontend/ci: Build-Hinweis in die App-Quelle, env-gesteuert; Prod-Build ohne

Der Latest-Build-Hinweis wandert vom Workflow-sed in die App (app.js,
mountBuildBadge), damit ihn auch der Dev-Server zeigt — ein Post-Build-sed
erreicht den Dev-Server nicht. Logik umgekehrt: Hinweis ist der Normalfall,
nur die produktive Installation schaltet ihn ab.

Drei Zustaende ueber Vite-Env VITE_BUILD_BADGE (Auswertung in app.js):
- Dev-Server (import.meta.env.DEV) -> 🔧 "Vorschau/lokaler Entwicklungsstand"
- Default `npm run build` (Env ungesetzt) -> 🚧 "latest build"; der Pages-
  Deploy nutzt den Default und traegt den Hinweis dadurch automatisch (die
  sed-Injektion entfaellt).
- `npm run build:prod` (Vite-Modus prod, .env.prod: VITE_BUILD_BADGE=none)
  -> KEIN Badge; esbuild eliminiert den Zweig als toten Code.

Verifiziert zur Laufzeit (Dev + `vite preview` auf beiden Builds): 🔧 im Dev,
🚧 im Default-Build, gar nichts im Prod-Build (Titel sauber "Werkbaum").
34 Vitest-Tests gruen, Workflow-YAML/Shell gueltig.

Doku: D16 fortgeschrieben (quellbasiert/env statt sed, Begruendung); README
(de/en) mit Prod-Build-Anleitung inkl. LICENSE-/Versions-Caveats; frontend/
CLAUDE.md; .claude/launch.json bekommt einen frontend-dist-Preview (vite
preview, Port 8138) zum Verifizieren gebauter Dateien.

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

docs/DECISIONS.md

@@ -135,18 +135,29 @@ zählt der flache CI-Klon nur einen Commit. `1.0` bleibt die Version beim lokale
 Links**: „Werkbaum" → Repo-Startseite, die Versionsnummer (`<a class="ver">`) →
 exakt der deployte Commit (`…/commit/<sha>`, im Build via `git rev-parse HEAD`).
 
-**Latest-Build-Hinweis:** Der Pages-Deploy ist der jeweils frischeste
-Entwicklungsstand und kann Fehler enthalten; die *eigentliche* (stabile) Instanz
-läuft woanders. Damit nur diese Veröffentlichung als „latest build" markiert ist,
-injiziert der Workflow — nach demselben Muster wie Version/LICENSE, also **nur auf
-der Site-Kopie** — hinter dem Titel (`</h1>`, im Bundle eindeutiger Anker) ein
-kleines Symbol mit Tooltip (`<span class="build-badge">🚧</span>`, zweisprachiger
-`title`). Die Quelle bleibt unberührt: ein schlichter `npm run build` (z. B. für
-die stabile Instanz) erzeugt die Datei **ohne** Hinweis. Bewusst nicht als
-i18n-UI-Text im `I18N`-Objekt, weil es kein Produkt-Feature ist, sondern
-Deploy-Metainformation genau dieser Pipeline (D14: die Quelle nicht um
-Deploy-Spezifika erweitern). Umgesetzt mit literalen UTF-8-Zeichen im
-`sed`-Replacement (kein `#`/`&`, sonst kollidiert der Delimiter).
+**Build-Hinweis (Vorschau / „latest build"):** Nicht-produktive Builds tragen
+hinter dem Titel ein kleines Symbol samt Tooltip, damit klar ist, dass es nicht
+die *eigentliche* (stabile) Instanz ist. Drei Zustände, gesteuert per Vite-Env
+`VITE_BUILD_BADGE` (Auswertung in `app.js`, `mountBuildBadge`):
+
+- **Dev-Server** (`import.meta.env.DEV`) → 🔧 „Vorschau – lokaler Entwicklungsstand".
+- **Default-Build** `npm run build` (Env ungesetzt) → 🚧 „latest build …". Der
+  GitHub-Pages-Deploy nutzt genau diesen Default und trägt den Hinweis dadurch
+  automatisch — **keine** `sed`-Injektion mehr nötig.
+- **Produktions-Build** `npm run build:prod` (Vite-Modus `prod`, `frontend/.env.prod`
+  setzt `VITE_BUILD_BADGE=none`) → **kein** Badge; esbuild eliminiert den Zweig
+  als toten Code, das Symbol steht dann nicht einmal mehr im Ausgabe-Quelltext.
+
+Damit trägt einzig die echte produktive Installation keinen Hinweis. **Warum in
+die App-Quelle statt per Workflow-`sed` (frühere Lösung):** Nur so sieht der
+Dev-Server den Hinweis ebenfalls — ein Post-Build-`sed` erreicht den Dev-Server
+nicht, der die Quelle direkt ausliefert. Die Umkehrung „Hinweis ist der
+Normalfall, Prod schaltet ab" passt zudem zur Anforderung (nur Prod bleibt sauber)
+und macht den Default sicher: wer den Prod-Schritt vergisst, veröffentlicht einen
+sichtbar als Entwicklungsstand markierten Build, nicht versehentlich einen als
+stabil wirkenden. Bewusst **kein** i18n-UI-Text im `I18N`-Objekt (kein
+Produkt-Feature, sondern Build-Metainformation; D14) — der `title` ist knapp
+zweisprachig (DE · EN).
 
 (Nummerierung: D15 war bereits für den kompakten Modus vergeben, daher D16.)
 

docs/TASKS.md

@@ -52,7 +52,7 @@ Abhaken beim Erledigen; neue Aufgaben unten anfügen.
 - [x] GitHub-Pages-Workflow angelegt (`.github/workflows/pages.yml`,
       siehe docs/DECISIONS.md D16).
 
-## Phase 3 — Integrationen (siehe docs/ROADMAP.md)
+## Phase 3 — Integrationen (siehe [ROADMAP](ROADMAP.md))
 - [ ] Backend-Gerüst per Spring Initializr in `backend/` anlegen
       (Kotlin, Gradle Kotlin DSL, JDK 21; Konventionen: backend/CLAUDE.md).
 - [ ] SVG-Renderer (Layout-Engine) als gemeinsame Basis für Export und