docs: Merge statt Rebase als Regel im Git-Workflow

Ein Rebase spielt jeden alten Commit einzeln neu ein und erzeugt Konflikte, die
inhaltlich nicht bestehen. Konkret im dotfiles-Repo: Commit 55d9733 vom 05.07.
setzt in settings.json den Modellnamen und ergaenzt tui. Auf origin/main stand
beides schon, nur an verschobener Position — der Rebase konnte den alten Patch
nicht mehr zuordnen und meldete Konflikt, obwohl die Datei in HEAD und
origin/main byte-identisch war. Zusaetzlich haette er vier vorhandene
Merge-Commits umgeschrieben.

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

dotfiles/CLAUDE.md

@@ -64,6 +64,7 @@ Niemals direkt auf `main` committen. Alle Aenderungen ueber Feature-Branches und
 
 - **Ausnahme `.commit-on-main`:** Vor dem Branchen im Repo-Root (`git rev-parse --show-toplevel`) auf die Marker-Datei `.commit-on-main` pruefen. Existiert sie, sind Direkt-Commits auf `main` erlaubt — dann kein Feature-Branch und kein PR, direkt auf `main` committen und pushen.
 - **Kleinteilige Commits:** Pro Commit nur ein einziges Thema. Nur die zum Thema gehörenden Dateien committen — keine thematisch gemischten Commits.
+- **Immer mergen, nie rebasen:** Divergierte Branches per `git pull` (Merge) zusammenfuehren, nicht per `git pull --rebase`. Ein Rebase spielt jeden alten Commit einzeln neu ein und erzeugt dabei Konflikte, die inhaltlich gar nicht bestehen — etwa wenn ein Wert am Ziel schon gesetzt, aber an eine andere Stelle der Datei gewandert ist. Ausserdem schreibt er vorhandene Merge-Commits um. Ein Merge vergleicht nur die Endzustaende. Rebase nur auf ausdruecklichen Wunsch.
 - **Commit-Messages:** Conventional Commits, deutsche Beschreibung
   - Subject: `<type>: <Beschreibung>` — max 72 Zeichen, kein Punkt am Ende
   - Typen: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `build`, `style`