fix: berechne-alle-winkel Signatur-Nachzug (schon-flach) + HundM05-Menu-Fix nachgezogen

Lisp/vf_standard.lsp: berechne-alle-winkel um Parameter schon-flach
erweitert (Fussabdruck-Korrektur, wenn ein Frame flach statt bei 3 Grad
ankommt) - vf_linienzug.lsp rief die Funktion bereits mit diesem 5.
Argument auf, dieser Commit fehlte im letzten Commit und liess den
Zwischenstand mit Argumentzahl-Mismatch zurueck. tests/test_foerderer.lsp
und tests/test_mubea.lsp ziehen dieselbe Signatur nach (inkl.
berechne-horizontale-mitte, das schon-flach bereits erwartete).
tests/testdata/linienzug_tests*.json aktualisiert passend zum echten
Bau-Ablauf. menu/SSG_LIB.mnu/.cui: TEST_LINIENZUG_STUFE2 im Testmenue
ergaenzt.

Lisp/vf_spec.lsp + lib/vf_spec_export.py: *vsp-menu-start* auf die aktuelle
6-Optionen-Kettenanfang-Zuordnung umgestellt (vorher noch 4 Optionen) -
vsp-journal replayt gegen den LEBENDEN vf-linienzug-modus. Python-Tabelle
bewusst NICHT umgestellt (dekodiert eine eingefrorene Alt-Aufzeichnung).
TEST_HUNDM05 schlaegt trotzdem weiterhin fehl (separates, ungeloestes
Problem - siehe naechster Absatz).

Bekannter offener Fehler: TEST_HUNDM05 baut nach wie vor nicht korrekt -
der Menu-Code-Fix allein reicht nicht. Root Cause nicht abschliessend
geklaert, Uebergabe an Kollegen fuer Logik-Review vorgesehen.

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

lib/vf_spec_export.py

@@ -71,6 +71,28 @@ ENDE2 = {"1": "ja-mit-es", "2": "nein"}
 # haengt am Frame: die ERSTE Sektion laeuft ohne Frame und bekommt 4 Optionen
 # (kein GF-Bogen - es gibt noch keine Richtung, an die er anschliessen
 # koennte), jede spaetere 5. Siehe vf-linienzug-modus.
+#
+# WICHTIG (2026-09-12): vf-linienzug-modus wurde SPAETER um "GF-Bogen"/
+# "Vario-Kurve" auch am Kettenanfang erweitert (6 statt 4 Optionen dort,
+# "Fortsetzung einer bestehenden Teilkette" - Referenzrichtung kommt dann aus
+# einem KS_AUS am Startpunkt). Lisp/vf_spec.lsp's *vsp-menu-start* wurde
+# entsprechend auf die NEUE 6er-Zuordnung umgestellt, WEIL vsp-journal seine
+# Tokens durch den AKTUELLEN (lebenden) vf-linienzug-modus REPLAYT - der
+# Code muss dort zur JETZT gueltigen Menue-Reihenfolge passen.
+#
+# Diese Python-Tabelle bleibt bewusst auf der ALTEN 4er-Zuordnung: sie
+# decodiert tests/testdata/hm_recformat.json - eine EINGEFRORENE Aufzeichnung
+# einer echten Kundenzeichnung, die zu einem Zeitpunkt VOR dieser Erweiterung
+# entstand (ihr roher Code fuer "Linie-GF" am Kettenanfang ist "1", nicht
+# "3"). Wuerde diese Tabelle auf die neue Zuordnung umgestellt, koennte
+# SpecReader die vorhandene Aufzeichnung nicht mehr korrekt lesen (siehe
+# Testfall test_verlustfrei in tests/test_vf_spec.py). Die Tokenfolgen von
+# LISP (vsp-journal, GEGEN den lebenden Bau-Ablauf) und Python (hier, GEGEN
+# die eingefrorene Aufzeichnung) sind fuer "Linie-GF" am Kettenanfang darum
+# ab dieser Erweiterung bewusst NICHT mehr identisch - eine unvermeidbare
+# Folge davon, dass sich die Menue-Struktur nach der Aufzeichnung geaendert
+# hat. Wird hm_recformat.json je aus einer NEUEN Aufzeichnung (mit dem
+# aktuellen 6-Optionen-Ablauf) neu erzeugt, muesste diese Tabelle mitziehen.
 MENU_START = {"Linie-GF": "1", "Linie-VF": "2", "Horizontal-VF": "3",
               "Linie": "4"}
 MENU_WEITER = {"GF-Bogen": "1", "Linie-GF": "2", "Linie-VF": "3",