Geviertstriche aus Text, Kommentaren und Doku entfernen

467 Stellen. Nicht durch einen anderen Strich ersetzt, sondern durch das
Satzzeichen, das an der jeweiligen Stelle richtig ist: Doppelpunkt, wo eine
Erlaeuterung folgt; Komma, wo der Satz weiterlaeuft; Punkt, wo zwei
Hauptsaetze aneinanderstiessen. Ein Halbgeviertstrich waere nur derselbe
Griff mit kuerzerem Strich gewesen.

Regelbasiert ersetzt und danach nachgeprueft, weil eine Regel allein nicht
reicht. Gefunden und einzeln korrigiert:

- Eingeschobene Saetze mit Strichpaar. Nur der oeffnende Strich passte ins
  Muster, der schliessende blieb als "—," stehen. Drei Stellen, jetzt mit
  Klammern oder als eigener Satz.

- Doppelte Doppelpunkte, wo beide Striche eines Paars zu Doppelpunkten wurden
  ("Globale Regeln: Schrift, Groessen, Abstaende: kommen aus HiveGrid").
  Sieben Stellen in Doku und Oberflaeche, jetzt in Klammern.

- Pfade, denen ein Komma statt eines Doppelpunkts folgte.

- Ausgerichtete Kommentartabellen, in denen der Strich eine Spalte war.

Nicht angefasst: drei Geviertstriche, die keine Prosa sind, sondern
Tabellenplatzhalter fuer "kein Wert" (Trichter, Auftraege, Kunden). Dort ist
der Strich die Angabe selbst; ihn zu entfernen liesse leere Zellen zurueck.

tsc, lint, build, verify:carbon und verify:layout laufen sauber.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX

docs/DATENMODELL.md

@@ -10,15 +10,15 @@ Einbau nur die Datenquelle getauscht werden muss.
 
 | Prototyp | HiveGrid-Entity | Verfügbar | Anmerkung |
 |---|---|---|---|
-| `Rechnung` | **`Rechnung`** (Sub-Entity am Projekt) | v1 | Status dort `entwurf/gestellt/bezahlt/storniert` — **kein `ueberfaellig`**. Überfälligkeit wird aus `faellig_am` gegen heute abgeleitet, nicht als Status geführt |
+| `Rechnung` | **`Rechnung`** (Sub-Entity am Projekt) | v1 | Status dort `entwurf/gestellt/bezahlt/storniert`: **kein `ueberfaellig`**. Überfälligkeit wird aus `faellig_am` gegen heute abgeleitet, nicht als Status geführt |
 | `Auftrag` | **`Projekt`** in einer Pipeline mit `typ_hint = auftrag` | v1 | „Auftrag" ist nach **AD-20 keine eigene Entität**, sondern eine Pipeline-View auf den Projekt-Kern. Wert = `auftragsvolumen`, Status = `stage_id` und damit **pipeline-intern** |
 | `Kunde` | **`Kontakt`** mit `kontakt_status = kunde` | v1 | „Kunde" ist ein **Status am Kontakt**, keine Entität. Kontakt ist der Oberbegriff (Privatperson/Organisation); die Verknüpfung zum Projekt läuft über `ProjektKontakt` mit Rolle `auftraggeber` |
 | `Mitarbeiter` | `TenantUser` + `User` | v1 | |
-| `Zeiteintrag` | — | **v2** | **Zeiterfassung steht im v2-Backlog.** Damit hat die gesamte Team-Seite in v1 keine Datenquelle — siehe unten |
+| `Zeiteintrag` |: | **v2** | **Zeiterfassung steht im v2-Backlog.** Damit hat die gesamte Team-Seite in v1 keine Datenquelle: siehe unten |
 
 > **Die Begriffe des Prototyps sind SHK-Fachsprache, nicht das Datenmodell der
 > Software.** „Auftrag" und „Kunde" existieren dort nicht als Entitäten. Das ist
-> kein Fehler des Prototyps — der Betrieb spricht so, und die Oberfläche soll so
+> kein Fehler des Prototyps, der Betrieb spricht so, und die Oberfläche soll so
 > sprechen. Beim Einbau ist es aber eine Übersetzungsleistung und keine
 > Eins-zu-eins-Zuordnung.
 
@@ -30,8 +30,8 @@ Auslastung, Produktivquote, erfasste Stunden und Abwesenheiten beruhen alle auf
 
 1. Team-Seite als v2 einplanen und in v1 nicht ausliefern;
 2. Stunden aus einem Drittsystem anbinden (der Betrieb erfasst sie ohnehin
-   irgendwo) — dann ist es eine Integrationsfrage, keine Modellfrage;
-3. Zeiterfassung nach v1 ziehen — die größte Entscheidung von den dreien.
+   irgendwo): dann ist es eine Integrationsfrage, keine Modellfrage;
+3. Zeiterfassung nach v1 ziehen, die größte Entscheidung von den dreien.
 
 Das ist eine Produktentscheidung, keine Gestaltungsfrage. Sie gehört vor den
 Einbau geklärt, weil sie eine von fünf Seiten betrifft.
@@ -60,7 +60,7 @@ hat. Ohne dieses Feld müsste der Trichter raten und würde die oberen Stufen
 systematisch zu klein zeigen.
 
 `ueberAngebot` trennt das Angebotsgeschäft (ab etwa 6.000 €) von Aufträgen, die
-direkt beauftragt werden — Wartung, Notdienst, E-Check. Trichter und
+direkt beauftragt werden: Wartung, Notdienst, E-Check. Trichter und
 Abschlussquote beziehen sich ausschließlich auf das Angebotsgeschäft.
 
 **Rechnung:** `entwurf` · `gestellt` · `bezahlt` · `ueberfaellig`.
@@ -84,7 +84,7 @@ Lüftungsanlage.
 
 ## Der Demo-Datensatz
 
-Erzeugt mit festem Seed (`mulberry32`, Seed `20260730`) — die Zahlen bleiben
+Erzeugt mit festem Seed (`mulberry32`, Seed `20260730`): die Zahlen bleiben
 über Reloads und Screenshots identisch. Bezugsdatum ist der **30.07.2026**
 (`HEUTE` in `utils/dateUtils.ts`).
 
@@ -104,15 +104,15 @@ Fiktiver Betrieb: **Meister Krause GmbH**, Raum Rhein-Main, 24 Beschäftigte
 
 **Eingebaute Effekte**, damit die Charts nicht künstlich flach aussehen:
 
-- **Saisonalität** — Heizung und Lüftung ziehen von September bis Februar an,
+- **Saisonalität**: Heizung und Lüftung ziehen von September bis Februar an,
   der Hochsommer ist schwächer (`SAISON_INDEX`)
-- **Wachstum** — rund 12 % gegenüber dem Vorjahr
-- **Größenabhängige Abschlussquote** — Wartung und Notdienst werden fast immer
+- **Wachstum**, rund 12 % gegenüber dem Vorjahr
+- **Größenabhängige Abschlussquote**: Wartung und Notdienst werden fast immer
   ausgeführt, große Anlagen dagegen verglichen und häufiger verloren
-- **Zahlungsverhalten** — die Mehrheit zahlt nahe am Zahlungsziel (21 Tage),
+- **Zahlungsverhalten**, die Mehrheit zahlt nahe am Zahlungsziel (21 Tage),
   ein kleiner Rest wird zum Mahnfall; Forderungen älter als sieben Monate sind
   eingebracht oder ausgebucht und stehen nicht mehr in der offenen Liste
-- **Förderanträge** — nur bei Vorgängen der letzten rund 100 Tage offen; ein
+- **Förderanträge**, nur bei Vorgängen der letzten rund 100 Tage offen; ein
   Bescheid dauert Wochen, nicht Jahre
 
 Diese Effekte sind fachlich begründet, nicht kosmetisch: Ein gleichverteilter