docs(16): record WR-01..WR-04 fix resolution in review and 16-03 summary

Marks all four Warning findings from 16-REVIEW.md as resolved with their
fix commit hashes; the two Info findings (IN-01/IN-02) remain open and
out of scope for this fix pass. Appends a note to 16-03-SUMMARY.md
recording the WR-02/WR-03/WR-04 behavior change in
syncBoundGroupsForTenant(), since that summary still described the
pre-fix behavior.

.planning/phases/16-ad-gruppen-synchronisation/16-03-SUMMARY.md

@@ -216,6 +216,18 @@ None — keine externe Service-Konfiguration erforderlich. Der laufende Docker-S
 - Plan 16-04 (Dialog-Umbau) und 16-05 (Anzeige-Fallback Frontend, Requirement-Abschluss PERM-02) koennen auf dieser Grundlage aufsetzen
 - **Offener Punkt bleibt bestehen (WINDOWS.md #4):** A1/A2-Live-Pruefung gegen ein echtes Active Directory (ViCoTest) muss nachgeholt werden, bevor die Loeschsemantik aus D-05 als produktionsreif gilt — siehe Abschnitt „Outstanding Live Verification" oben
 
+## Post-Review Fix (16-REVIEW.md, 2026-08-06)
+
+Der Code-Review dieser Phase (`16-REVIEW.md`) fand drei Warnungen an genau der in diesem Plan gebauten `syncBoundGroupsForTenant()`-Methode. Alle drei sind seither behoben — die obige Beschreibung dieses Plans spiegelt noch den Vor-Fix-Stand wider, daher dieser Nachtrag:
+
+- **WR-02 (Commit `1971795`):** Der Rename-Zweig meldete jeden P2002 beim Zurückschreiben von `name`/`ldapDn` pauschal als Namenskollision, ohne `updateError.meta.target` zu prüfen — obwohl der Aufruf zwei verschiedene Unique-Indizes treffen kann. Behoben durch dieselbe Ziel-Prüfung, die `importGroupsByDn()` bereits nutzte.
+- **WR-03 (Commit `00de6a6`, der wichtigste der drei Punkte):** Der Existenz-Sweep vor einer Löschung suchte ausschließlich unter den konfigurierten Base-DNs. Eine AD-Gruppe, die in eine andere OU verschoben (nicht gelöscht) wurde, lieferte dort `searchEntries.length === 0` und wurde fälschlich als „verschwunden" gelesen und samt Mitgliedschaften/Modulfreigaben gelöscht — Zugriffsverlust durch eine reine Verzeichnis-Umstrukturierung, kein tatsächliches AD-Löschen. Die Methode führt jetzt vor jeder Löschung einen zweiten, weiter gefassten Sweep gegen die Domänen-Wurzel jeder konfigurierten Base-DN aus; ein Treffer dort verhindert die Löschung und wird stattdessen als Fehlerzeile gemeldet. Erst wenn auch dieser weite Sweep leer bleibt, gilt SC-4/D-05 als tatsächlich erfüllt.
+- **WR-04 (Commit `2779d42`):** Die Umbenennungs-Erkennung verglich `cn`/`dn` byteweise. Eine reine Groß-/Kleinschreibungs-Abweichung zwischen zwei Sync-Läufen (z. B. nach einem Domain-Controller-Wechsel) hätte jedes Mal fälschlich eine Umbenennung ausgelöst und die Idempotenz-Garantie verletzt. Der Vergleich zur Entscheidung „ist das eine Umbenennung" ist jetzt case-insensitive; der tatsächlich gespeicherte Wert bleibt weiterhin exakt der vom Verzeichnis gemeldete (D-03 unangetastet).
+
+(WR-01, in `groups.service.ts`, betrifft nicht diese Methode — siehe `16-02-SUMMARY.md`. Commit `dd59bf5`.)
+
+Alle vier Fixes sind mit neuen Tests in `ldap.service.spec.ts` bzw. `groups.service.spec.ts` abgesichert; die volle API-Suite lief zuletzt gruen. Details siehe `16-REVIEW.md`.
+
 ---
 *Phase: 16-ad-gruppen-synchronisation*
 *Completed: 2026-08-06*