Update AD group name length finding status

Sonstiges/LIAM_Finding.md

@@ -202,14 +202,21 @@ Betroffene Stellen:
 
 Status:
 
-- Offen, noch nicht umgesetzt.
+- Am 2026-03-18 umgesetzt.
+- Vor der AD-Gruppenerzeugung wird jetzt zentral eine konservative Namensgrenze von 64 Zeichen angewendet.
+- Die Begrenzung reserviert zusätzlich Platz für einen möglichen `LOOP`-Suffix, damit spätere Kollisionsauflösung nicht wieder über das sichere Limit hinausschießt.
+- Die Kürzung greift nur auf dem dynamischen Pfadanteil, nicht auf stabilen fachlichen Tags wie Prefix, Scope oder Gruppentyp.
+- Die gemeinsame Logik wird sowohl im normalen Security-Group-Pfad als auch im Traverse-Pfad verwendet.
+- Wenn gekürzt werden muss, wird das nur im Log protokolliert. Es wird kein fachlicher Fehler geworfen.
+- Die Implementierung arbeitet bewusst ohne Hash-Fallback, damit die resultierenden Namen vollständig human-readable bleiben.
+- Verifiziert mit `msbuild LiamNtfs/LiamNtfs.csproj /p:Configuration=Debug`. Das bestehende Warning `CS0162` in `SecurityGroup.cs` blieb unverändert.
 
 Vorschlag zum Fixen:
 
 - Vor dem AD-Write jeden final generierten Gruppennamen gegen eine zentrale, konservative Maximalgrenze prüfen, die für die tatsächlich beschriebenen AD-Attribute sicher eingehalten wird.
 - Wenn ein Name innerhalb der Grenze liegt, unverändert weiterarbeiten.
 - Wenn ein Name zu lang ist, keinen fachlichen Fehler werfen, sondern den Umstand nur im Log dokumentieren und anschließend automatisch auf einen kontrolliert verkürzten Namen umschalten.
-- Die Verkürzung sollte deterministisch sein und die stabilen fachlichen Tags erhalten. Kürzen sollte möglichst nur der dynamische Pfadanteil (`NAME` bzw. `RELATIVEPATH`). Wenn das nicht reicht, sollte als Fallback ein stabiler Hash-/Kurzschlüssel im dynamischen Mittelteil verwendet werden, damit der Name reproduzierbar und kollisionsarm bleibt.
+- Die Verkürzung sollte deterministisch sein und die stabilen fachlichen Tags erhalten. Kürzen sollte möglichst nur der dynamische Pfadanteil (`NAME` bzw. `RELATIVEPATH`).
 - Der bestehende `LOOP`-Mechanismus zur Kollisionsbehandlung sollte danach unverändert weiterlaufen, damit Längenbegrenzung und Eindeutigkeitslogik sauber getrennt bleiben.
 
 Konkreter Vorschlag für die Verkürzungslogik:
@@ -220,12 +227,10 @@ Konkreter Vorschlag für die Verkürzungslogik:
 - Wenn `dynamicPart` aus `NAME` stammt, wird zuerst nur dieser Name gekürzt.
 - Wenn `dynamicPart` aus `RELATIVEPATH` stammt, sollte segmentbasiert gekürzt werden. Das letzte Segment bleibt möglichst am längsten erhalten, weil es fachlich meist den eigentlichen Zielordner beschreibt.
 - Erste Kürzungsstufe: frühe oder mittlere Segmente verkürzen, bevor das letzte Segment gekappt wird. Beispiel: `Abteilung_Standort_Projekt_Unterordner` wird eher zu `Abt_Sta_Proj_Unterordner` als zu `Abteilung_Standort_Projekt_Unter`.
-- Zweite Kürzungsstufe: wenn die segmentbasierte Verkürzung noch nicht reicht, den mittleren Teil durch einen stabilen Kurzschlüssel ersetzen und Anfang sowie Ende lesbar lassen.
-- Der Kurzschlüssel sollte aus dem ungekürzten Original von `dynamicPart` berechnet werden, nicht aus dem bereits gekürzten Ergebnis. Dadurch bleibt das Resultat reproduzierbar.
-- Als technisches Schema bietet sich `sichtbarerAnfang + "_" + hash8 + "_" + sichtbaresEnde` an. So bleibt der Name lesbar, aber trotzdem kollisionsarm.
-- Für den Hash genügt ein stabiler technischer Fingerprint wie `SHA1` oder `SHA256`, von dem nur wenige Zeichen, z. B. 8 Hex-Zeichen, verwendet werden.
+- Zweite Kürzungsstufe: wenn die segmentbasierte Verkürzung noch nicht reicht, werden zuerst die frühen Segmente weiter reduziert und danach bei Bedarf ganze frühe Segmente entfernt, bevor das letzte Segment angetastet wird.
+- Nur wenn kein frühes Segment mehr sinnvoll gekürzt oder entfernt werden kann, wird das letzte verbleibende Segment weiter reduziert.
 - Vor der Kürzung muss bereits Reserve für einen möglichen `LOOP`-Suffix eingeplant werden, damit die spätere Kollisionsauflösung nicht erneut über die Maximalgrenze hinausschießt.
-- Logging nur dann, wenn tatsächlich gekürzt wurde. Im Log sollten Originalname, Zielname, alte Länge, neue Länge und die verwendete Strategie (`truncate-name`, `truncate-relativepath`, `hash-fallback`) stehen.
+- Logging nur dann, wenn tatsächlich gekürzt wurde. Im Log sollten Originalname, Zielname, alte Länge, neue Länge und die verwendete Strategie (`truncate-name`, `truncate-relativepath`) stehen.
 - Die gesamte Logik sollte in einer zentralen Hilfsmethode gekapselt werden, damit Create, Ensure, Traverse und Preview denselben Namensalgorithmus verwenden.
 
 ### 9. Mittel-Hoch: `LoadDataArea()` behandelt UNC-Pfade fachlich falsch