feat(dashboard): Startansicht mit Bewerbungen, Wandlung und Gewinnen

Erster Menuepunkt und Startansicht; das Logo oben links fuehrt dorthin zurueck.

Vier Kennzahlen (Bewerbungen, daraus Opportunities samt Quote, gewonnene
Projekte, aktuell beim Kunden), ein Saeulendiagramm mit denselben drei Reihen
ueber der Zeit, die Bewerbungen je Berater, die naechsten Termine und alle
Opportunities in Kundenvorstellung bzw. Interview Kunde. Zeitraum ueber vier
Vorgaben oder frei, Einteilung nach Tag, Monat, Quartal oder Jahr.

Bewerbung heisst dabei: ein Eintrag in der Akquise - jeder Eintrag bedeutet, dass
ein Profil raus ist (so vom Nutzer festgelegt).

Zwei Dinge dafuer am Datenmodell:

- crm_opportunities.won_at haelt den Zeitpunkt des Wechsels nach "Beauftragt".
  Die Phase allein sagt nur, wie es jetzt steht, nicht wann es passiert ist.
  Beim Wechsel heraus wird das Datum geleert, sonst zaehlt das Dashboard einen
  Gewinn, den es nicht gibt.
- Die Akquise loescht nach 90 Tagen - damit waere jede Jahresauswertung falsch.
  Der Aufraeumlauf sichert deshalb vorher Tag, Berater und Anzahl in
  crm_acquisition_history, in derselben Transaktion wie das Loeschen. Gesichert
  wird nur, was verschwindet; die Auswertung addiert beide Quellen und kann sich
  damit nicht ueberschneiden. Projektdaten sind nach dem Loeschen weiterhin weg.

Termine und die Phasenlisten kommen nicht aus einem eigenen Endpunkt: Termine und
Opportunities laedt die App ohnehin komplett, das Dashboard filtert sie selbst.

Diagramme von Hand (SVG-freie Balken plus Tailwind-Uebergaenge) statt einer
Bibliothek - drei Darstellungen rechtfertigen keine weitere Abhaengigkeit, und so
kommen die Farben aus denselben Tokens wie der Rest. Die Zahlen laufen hoch, die
Saeulen wachsen; wer Bewegung im System abgeschaltet hat, bekommt sofort den
Endwert.

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

docs/02-datenmodell.md

@@ -71,6 +71,7 @@ erDiagram
         date last_interaction_at
         varchar next_step
         int owner_id FK
+        datetime won_at "Wechsel nach Beauftragt"
         datetime deleted_at "Papierkorb; nach 90 Tagen weg"
     }
     crm_opportunity_contacts {
@@ -95,6 +96,11 @@ erDiagram
         enum field "sender | channel | consultant"
         varchar value "Inhalt des Dropdowns"
     }
+    crm_acquisition_history {
+        date found_on PK
+        varchar consultant PK
+        int applications "verdichtet vor dem Loeschen"
+    }
     crm_events {
         int id PK
         varchar title
@@ -110,7 +116,7 @@ erDiagram
     }
 ```
 
-Sieben Eigenheiten, die man kennen muss:
+Acht Eigenheiten, die man kennen muss:
 
 - **`crm_leads` führt zwei Bestände.** `mail_pool = 0` ist der gepflegte
   Kontaktbestand, `mail_pool = 1` der Vorbereich „Aus Mails" mit den Funden des
@@ -127,6 +133,15 @@ Sieben Eigenheiten, die man kennen muss:
 - **`avatar` ist eine Data-URL in der Datenbank.** Der Browser verkleinert jedes
   Bild vor dem Upload auf 256 px (`src/lib/imageCompress.ts`), aus 2,9 MB werden
   wenige Kilobyte.
+- **Das Dashboard rechnet aus zwei Quellen.** Jeder Eintrag in
+  `crm_acquisitions` ist eine versendete Bewerbung. Weil die Akquise nach 90
+  Tagen löscht, sichert der Aufräumlauf vorher Tag, Berater und Anzahl in
+  `crm_acquisition_history` - in derselben Transaktion, sonst würde ein Abbruch
+  zwischen Sichern und Löschen denselben Tag doppelt zählen. Die Auswertung liest
+  beide Quellen und addiert sie; überschneiden können sie sich nicht, weil genau
+  das gesichert wird, was verschwindet. `crm_opportunities.won_at` hält den
+  Zeitpunkt des Wechsels nach *Beauftragt* - die Phase allein sagt nur, wie es
+  jetzt steht, nicht wann es passiert ist.
 - **Gelöschte Opportunities bleiben stehen.** `crm_opportunities.deleted_at`
   setzt sie in den Papierkorb; alle Abfragen blenden sie aus. An einer
   Opportunity hängen Ansprechpartner, Verlauf und Mailzuordnungen - ein Fehlklick