test: U-Form-Faelle, Formkriterium laengs und Reihenanordnung der Linienzug-Tests

Drei neue Modus-2-Testfaelle aus echten Laeufen, ein Kriterium, das eine
heute eingebaute Fehlgeometrie gefunden haette, und ein aufgeraeumtes
Layout der Testketten.

1. Drei U-Form-Faelle (tests/testdata/linienzug_modus2_uform_*.json),
   aufgezeichnet mit lib/vf_journal_export.py. Gefaltete Laeufe: der Pfad
   wechselt ueber zwei 90-Grad-Vario-Kurven dreimal die Fahrtrichtung, die
   Kletterstrecke liegt in einem ANDEREN Schenkel als der Lauf-Eingang -
   genau der am 2026-10-29 korrigierte Fall. Variiert werden GF-Verteilung
   (alles am Einlauf vs. 1/2+1/2) und Winkel; beides ist noetig, weil die
   Verteilung entscheidet, ob ueberhaupt GF im fremden Schenkel steht, und
   der Restfehler der alten Bilanz mit L_GF skalierte.
   c:TEST_LINIENZUG_MODUS2 ist dafuer tabellengesteuert - ein weiterer Fall
   ist jetzt eine Zeile in *tlz-m2-faelle*.

2. RUECKNAHME des Schluss-Solves (vfl-zsolve-schluss-ziel, heute frueh
   eingebaut). Er loeste den letzten Fueller gegen Richtung UND Laenge und
   traf den Zielpunkt dadurch in X und Y exakt - um den Preis, dass er die
   letzte Gerade um 6.15 Grad verdrehte (hz-plan -90 -> -96.15), in der
   Zeichnung als schiefer Schenkel sichtbar. Das widerspricht der
   Entscheidung vom 2026-10-26: quer MUSS 0 sein, LAENGS DARF ABWEICHEN -
   der Hauptstrang bleibt gerade, der seitliche Versatz des ES-Elements ist
   dessen Bauform. Die Messwerte von heute (0.56 / 0.7 mm quer) stammen
   nicht von dieser Aenderung, sondern von der Laengenbilanz des gefalteten
   Laufs (35ebee1) - der Zweig blieb dort ungenutzt. Die Begruendung steht
   jetzt an der Aufrufstelle, damit niemand den Solve erneut baut.

3. laengs wird geprueft - als FORM-, nicht als Genauigkeitskriterium
   (erwartung_laengs_mm, Toleranz 5 mm). Der Wert ist die Ausladung des
   ES-Elements und je Fall eine Konstante (104.68 bei ES_Element_30,
   637.58 bei ES_Element_90). Punkt 2 war am Querwert NICHT erkennbar - die
   Verdrehung macht ihn gerade null, der Test meldete OK, gefunden wurde sie
   mit dem Auge. Ein verdrehter Hauptstrang zielt auf den Endpunkt und
   drueckt laengs auf ~0; daran faellt er auf. Gegengeprueft: mit kuenstlich
   auf 0.01 mm gesetzter Toleranz kippen alle fuenf Faelle auf ABWEICHUNG.

4. Alle sieben Ketten des Menueeintrags entstehen als Reihe auf Y=0, 20 m
   Abstand, statt verstreut. Die Modus-1-Skripte brauchen dafuer nur ihren
   EINEN point_abs (alles Weitere ist point_rel mit dL/hz); bei Modus 2
   mussten PT-Eintraege UND die Pfadkoordinaten in SEGS (Felder 6..9)
   mitwandern, sonst zeigt der Pfad woanders hin als Start und Ziel.
   Reine Translation - Laengen, Winkel und die geprueften Abweichungen sind
   davon unabhaengig; Z blieb stehen, weil die Starthoehe ein Eingabewert
   des Solvers ist. Geprueft: erstes Segment beginnt exakt am Startpunkt,
   letztes endet exakt am Zielpunkt, Messwerte unveraendert.

5. Die drei letzten Verweise auf doc/VarioFoerderer_Linienzug_Prinzipien.md
   (bewusst unversioniert) tragen ihre Begruendung jetzt selbst: Entkopplung
   Neigung/XY, warum es genau EINEN Kletterer je Lauf gibt, und warum ein
   VF-Sub-Segment auf der 3-Grad-Basis beginnen und enden muss.

Geprueft: TEST_UNIT 897/897 (die 7 Tests der entfernten Funktion sind mit
ihr gegangen), TEST_LINIENZUG_MODUS2 5 von 5 OK, voller Menueablauf baut
sieben Ketten an den vorgesehenen Stellen.

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

tests/README.md

@@ -87,7 +87,44 @@ dem gewuenschten Modus:
   Lauf ohne manuellen Zusatzschritt, aber ohne gleichzeitige visuelle Kontrolle
   aller Zeichnungen am Ende. Sinnvoll fuer reine CI-artige Validierung.
 
-## Referenzfaelle Linienzug Modus 2 (manuell, mit Soll-Werten)
+## Anordnung der Linienzug-Testketten
+
+Der Menueeintrag **Tests -> Foerderer-Linienzug** faehrt drei Befehle
+nacheinander (`TEST_LINIENZUG`, `TEST_LINIENZUG_STUFE2`,
+`TEST_LINIENZUG_MODUS2`) und baut dabei **sieben** Ketten. Damit sie
+nebeneinander auf einer Grundlinie entstehen statt verstreut, tragen die
+Testdaten versetzte Startpunkte - 20 m Abstand, alle auf `Y = 0`:
+
+| X | Z | Kette | Datei |
+|---|---|---|---|
+| 0 | 2154 | Modus 1, Standardfall | `linienzug_tests.json` |
+| 20000 | 2154 | Modus 1, Stufe-2-Fallback | `linienzug_tests_stufe2.json` |
+| 40000 | 0 | Variante A (Vario-Kurve) | `linienzug_modus2_variokurve.json` |
+| 60000 | 0 | Variante B (GF-Bogen) | `linienzug_modus2_gfbogen.json` |
+| 80000 | 355 | U-Form 1 (GF alles am Einlauf) | `..._uform_gf1.json` |
+| 100000 | 711 | U-Form 2 (1/2 + 1/2) | `..._uform_halb.json` |
+| 120000 | 709 | U-Form 3 (steilerer Winkel) | `..._uform_halb_steil.json` |
+
+Die Koordinaten sind also **nicht** die der aufgezeichneten Laeufe, die
+uebrige Geometrie schon. Verschoben wurde rein translatorisch: Laengen,
+Winkel und die geprueften Abweichungen sind davon unabhaengig. `Z` blieb
+jeweils stehen - die Starthoehe ist ein Eingabewert des Solvers, kein
+Layout-Parameter.
+
+Technisch unterscheiden sich die beiden Datenarten: die Modus-1-Skripte
+brauchen nur ihren EINEN `point_abs` (alles Weitere ist `point_rel` mit
+`dL`/`hz`), waehrend bei Modus 2 sowohl die `PT`-Eintraege ALS AUCH die
+Pfadkoordinaten in `SEGS` (Felder 6..9) mitwandern muessen - sonst zeigt der
+Pfad woanders hin als Start und Ziel.
+
+## Referenzfaelle Linienzug Modus 2 (`c:TEST_LINIENZUG_MODUS2`)
+
+Fuenf aufgezeichnete Laeufe, die als zwei Paare gebildet sind: A/B
+unterscheiden die Eck-BAUTEILART, U-Form 1..3 den gefalteten Lauf nach
+GF-Verteilung und Winkel. Ausgefuehrt ueber Menue -> Tests ->
+Foerderer-Linienzug.
+
+### Erster und zweiter Fall: Eck-Bauteilart
 
 Zwei Laeufe auf **demselben gezeichneten Pfad**, die sich nur in der
 Segment-Klassifizierung unterscheiden. Sie decken die beiden Eck-Bauteilarten
@@ -132,20 +169,71 @@ letzte Gerade auf der gezeichneten Linie und der ES-`KS_AUS` landet seitlich
 daneben, oder umgekehrt. Entschieden ist: der Hauptstrang bleibt gerade, der
 seitliche Versatz des ES-Elements ist dessen Bauform und kein Fehler.
 
+**`laengs` wird trotzdem geprueft** - nicht als Genauigkeits-, sondern als
+FORMkriterium (`erwartung_laengs_mm` in den Testdaten, Toleranz 5 mm). Der Wert
+ist die Ausladung des ES-Elements und damit je Fall eine Konstante: 104.68 mm
+bei `ES_Element_30`, 637.58 mm bei `ES_Element_90`.
+Grund: am 2026-10-29 loeste ein Experiment den Schluss-Fueller gegen Richtung
+UND Laenge und traf den Zielpunkt dadurch in X und Y exakt - um den Preis, dass
+es die letzte Gerade um 6.15 Grad verdrehte. `quer` und `dZ` waren dabei NULL,
+der Test meldete brav OK, und der schiefe Schenkel fiel nur beim Blick in die
+Zeichnung auf. Ein verdrehter Hauptstrang zielt auf den Endpunkt und drueckt
+`laengs` von ~638 mm auf ~0 - genau daran ist er zu erkennen.
+Die Pruefung selbst ist gegengeprueft: mit einer kuenstlich auf 0.01 mm
+gesetzten Toleranz kippen alle fuenf Faelle auf ABWEICHUNG.
+
 Im Protokoll muessen die Zuschlags-Zeilen erscheinen: `AS-Fussabdruck`,
 `Eck-Korrektur` je Ecke, und bei Variante A zusaetzlich
 `Abschluss-Fussabdruck`. **Eine FEHLENDE Zeile ist das Warnsignal** - sie
 bedeutet, dass ein Eck-Bauteil nicht messbar war und die Ecke unkorrigiert
 blieb (so wurde der 2.4-mm-Rest bei Variante B gefunden).
 
-> Noch nicht automatisiert. Dafuer muesste der Testfall den Pfad selbst per
-> `entmake` zeichnen und das Eingabe-Journal replayen; das Journal einer
-> gebauten Kette laesst sich mit `lib/vf_journal_export.py` aus der Zeichnung
-> ziehen. Die reinen Rechenkerne dieser Faelle sind dagegen bereits file-frei
-> abgedeckt (`tu-tests-vfl-parallel` in `test_unit.lsp`: `vfl-eck-zerlegen`,
+> **Automatisiert seit 2026-10-27** als `c:TEST_LINIENZUG_MODUS2` (Menue:
+> Tests -> Foerderer-Linienzug). Der Pfad muss dafuer NICHT gezeichnet werden:
+> ein Modus-2-Journal traegt einen `SEGS`-Eintrag mit der kompletten
+> Segment-Essenz und ist damit von den Original-Objekten unabhaengig - der
+> Test spielt schlicht das mit `lib/vf_journal_export.py` ausgelesene Journal
+> ab. Die reinen Rechenkerne sind zusaetzlich file-frei abgedeckt
+> (`tu-tests-vfl-parallel` in `test_unit.lsp`: `vfl-eck-zerlegen`,
 > `vfl-es-achs-reserve`, `vfl-projiziere-neigung` - jeweils mit den echten
 > Messwerten aus diesen beiden Laeufen).
 
+### Dritter bis fuenfter Fall: gefalteter Lauf (U-Form)
+
+Aufgezeichnet 2026-10-29, Datendateien `tests/testdata/linienzug_modus2_uform_*.json`.
+
+Der Pfad wechselt ueber zwei 90-Grad-Vario-Kurven **dreimal die
+Fahrtrichtung**; die Kletterstrecke liegt dadurch in einem ANDEREN Schenkel als
+der Lauf-Eingang. Genau diese Konstellation war bis 2026-10-29 falsch
+bilanziert (gemessen 1424 mm quer), weil Posten dem falschen Schenkel
+zugerechnet wurden.
+
+| Segment | Art | Mass |
+|---|---|---|
+| 1 | Linie | L = 5855 mm, hz = 90 |
+| 2 | Bogen | 90 Grad rechts, R500 -> **Vario-Kurve aussen** |
+| 3 | Linie | L = 270 mm, hz = 0 (automatisch VF) |
+| 4 | Bogen | 90 Grad rechts, R500 -> **Vario-Kurve aussen** |
+| 5 | Linie | L = 7806 mm, hz = -90 (der Kletterer) |
+
+| Fall | GF-Verteilung | Winkel-Option | Testdatei |
+|---|---|---|---|
+| U-Form 1 | alles am Einlauf (GF1) | 2 | `..._uform_gf1.json` |
+| U-Form 2 | 1/2 GF1 + 1/2 GF2 | 2 (= 9 Grad) | `..._uform_halb.json` |
+| U-Form 3 | 1/2 GF1 + 1/2 GF2 | 3 (steiler) | `..._uform_halb_steil.json` |
+
+**Warum drei und nicht einer:** die GF-VERTEILUNG entscheidet, ob ueberhaupt
+Gefaellestrecke im fremden Schenkel steht (und damit, ob Nachrechner und das
+unterdrueckte Fueller-A greifen) - mit "alles am Einlauf" liegt das gesamte GF1
+dort, mit 1/2+1/2 nur die Haelfte. Der WINKEL ist noetig, weil der Restfehler
+der alten Bilanz mit `L_GF` skalierte: bei 6 Grad waren es 90 mm, bei 9 Grad
+934 mm. Zwei Laeufe mit demselben Winkel haetten den Fehler also beinahe
+verdeckt.
+
+Soll-Ergebnis wie oben: `quer` und `dZ` jeweils ~0 (gemessen 0.56 mm bei
+9 Grad und 0.7 mm bei der steileren Option), `laengs` ~638 mm - das ist die
+Ausladung des `ES_Element_90_links` und in allen drei Faellen gleich.
+
 ## alltests.json — Testregistry
 
 Die Datei `tests/alltests.json` ist die zentrale Registry aller Test-Module.