Fix sync duplicates and extreme slowness

Behebt Dubletten auf beiden Seiten und sehr langsame Syncs:

- Getrennte Hash-Baselines pro Seite (LastOutlookHash/LastStarfaceHash)
  statt eines gemeinsamen Hashes. Outlook und Starface stellen denselben
  Kontakt unterschiedlich dar, wodurch der gemeinsame Hash nie passte und
  bei jedem Lauf praktisch jeder Kontakt neu geschrieben wurde.
- Update-Methoden geben den frisch eingelesenen Stand zurueck, damit die
  Baseline nach dem Schreiben korrekt gesetzt wird (sauberes Konvergieren).
- Unvollstaendig geladene Starface-Liste bricht jetzt mit Fehler ab
  (inkl. Retry) statt still mit Teil-Liste weiterzuarbeiten - das liess
  Kontakte faelschlich als geloescht erscheinen und erzeugte Dubletten.
- Fehlender Starface-Kontakt (anderes Adressbuch) behaelt das Mapping,
  statt es zu verwerfen und neu anzulegen.
- Lockereres Re-Matching: gleicher E-Mail- oder voller Namens-Treffer
  reicht; umformatierte Telefonnummern blockieren ihn nicht mehr.
- Starface-Kontaktdetails werden parallel geladen (8 gleichzeitig).

Bestehende Mappings werden beim ersten Sync automatisch migriert.
CHANGELOG.md hinzugefuegt.

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

CHANGELOG.md

@@ -0,0 +1,65 @@
+# Changelog
+
+Alle nennenswerten Aenderungen an Starface Outlook Sync werden hier dokumentiert.
+
+Format orientiert sich an [Keep a Changelog](https://keepachangelog.com/de/),
+Versionsschema ist `x.x.x.x` (siehe `release.sh`).
+
+## [Unreleased]
+
+### Behoben
+
+- **Dubletten auf beiden Seiten beim Synchronisieren.** Mehrere zusammenhaengende
+  Ursachen wurden beseitigt:
+  - Eine unvollstaendig geladene Starface-Kontaktliste (z.B. durch einen
+    Lade-Fehler oder Timeout) liess die Engine Kontakte faelschlich als
+    "geloescht" ansehen, ihr Mapping verwerfen und sie beim naechsten Lauf neu
+    anlegen. Der Kontakt-Abruf bricht jetzt mit Fehlermeldung ab (inkl.
+    Wiederholversuch), statt still mit einer Teil-Liste weiterzuarbeiten.
+  - Ist ein Starface-Kontakt nicht in der geladenen Liste (z.B. anderes
+    Adressbuch), wird das Mapping jetzt **behalten** statt verworfen und neu
+    angelegt.
+  - Das Wiederzuordnen bestehender Kontakte war zu streng: eine von Starface
+    umformatierte Telefonnummer konnte einen eindeutigen E-Mail- oder
+    Namens-Treffer ueberstimmen und so eine Neuanlage statt Verknuepfung
+    ausloesen. Ein gleicher E-Mail- oder voller Namens-Treffer reicht jetzt.
+
+- **Synchronisation extrem langsam / schrieb bei jedem Lauf alle Kontakte neu.**
+  Die Aenderungserkennung verglich einen einzigen Hash gegen beide Seiten.
+  Outlook und Starface stellen denselben Kontakt aber unterschiedlich dar
+  (nicht uebertragene Felder, abweichendes Telefonformat), wodurch der Hash nie
+  uebereinstimmte und praktisch jeder Kontakt bei jedem Sync neu geschrieben
+  wurde. Jede Seite hat jetzt eine eigene Baseline (`LastOutlookHash` /
+  `LastStarfaceHash`); nur tatsaechlich geaenderte Kontakte werden geschrieben.
+
+### Geaendert
+
+- Starface-Kontaktdetails werden beim Laden parallel abgerufen (8 gleichzeitig)
+  statt einzeln nacheinander – deutlich schneller bei grossen Adressbuechern.
+- `UpdateContact` (Outlook) und `UpdateContactAsync` (Starface) geben jetzt den
+  frisch eingelesenen Stand zurueck, damit die Baseline nach dem Schreiben
+  korrekt gesetzt wird und der Sync sauber konvergiert.
+
+### Migration
+
+- Bestehende Mapping-Dateien werden beim ersten Sync automatisch uebernommen
+  (ein ruhiger Durchlauf ohne Massen-Update).
+- **Bereits vorhandene Dubletten werden nicht automatisch entfernt** – die Fixes
+  verhindern nur neue. Vorhandene Doppel-Kontakte einmalig manuell bereinigen.
+
+## [0.0.0.23]
+
+### Behoben
+
+- Kritischer Loesch-Fehler: Kontakte wurden bei einer geaenderten Outlook-EntryID
+  nicht mehr massenhaft geloescht.
+
+### Geaendert
+
+- Outlook-Sicherheitsschluessel werden fuer Domaenenumgebungen zusaetzlich nach
+  HKLM geschrieben (unterdrueckt die Outlook-Sicherheitsabfrage).
+
+## Aeltere Versionen
+
+Aeltere Releases (v0.0.0.1 – v0.0.0.22) sind ueber die Git-Historie und die
+Git-Tags nachvollziehbar.