fix: VF-Linienzug Journal-Reset, Spec-Grammatik (auf-ab/Linie-GF) und hz-Bug in HundM05

- vfl-journal-reset-lauf ans Funktionsanfang verschoben (Modus 1/2/3,
  Lisp/vf_linienzug.lsp): stand bisher nach der Startpunkt/Hoehe/AS-
  Praeambel und loeschte diese beim Reset selbst wieder - Journal begann
  mit dem ersten STEP-Marker statt PT, betraf jede Kette.
- Spec-Grammatik erweitert (Lisp/vf_spec.lsp, lib/vf_linienzug_grammatik.py,
  lib/vf_spec_export.py): "auf-ab" bei bereits flach ankommender Kette
  (Richtungswahl statt Zielhoehe) und neue Linie-GF-Fragereihenfolge
  (Kettenende direkt nach laenge_modus, inkl. vorgezogenem ES). Tests in
  tests/test_vf_spec.lsp/.py angepasst.
- lib/vf_linienzug_grammatik.py: _linie("kettenende_ziel") erwartete
  faelschlich ein hz-REAL nach der Distanz - der reale Bauablauf
  (vfl-body-abschluss) leitet die Richtung dort aus dem Frame ab und
  fragt sie nie. Fuehrte zu einem Token-Desync beim Dekodieren echter
  Kettenende-Journale.
- tests/testdata/hundm05.json (VF_hundm05_LZ_01): 5 ueberfluessige
  hz-Felder entfernt. vsp-linie injiziert bei JEDEM vorhandenen hz-Feld
  einen Richtungs-Token, unabhaengig vom tatsaechlichen Bauablauf - die
  Felder desyncten den Replay und liessen die Kette stumm mit der
  falschen (verkuerzten) Geometrie fertig bauen.

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

Lisp/vf_linienzug.lsp

@@ -5972,6 +5972,16 @@
   ;; zurueckgesetzt (spaeter im Ablauf) sowie unmittelbar vor jedem "Zurueck"-
   ;; Neuaufruf in vfl-modus-abbruch-sichern.
   (setq *vfl-wizard-abbruch-grund* nil)
+  ;; *vfl-journal* VOR dem allerersten vfl-in-*-Aufruf zuruecksetzen (nicht
+  ;; *vfl-replay-queue* - ein REPLAY-getriebener Aufrufer wie vsp-bau-aus-spec
+  ;; hat sie ueber vfl-journal-replay-start bereits VOR diesem Aufruf befuellt,
+  ;; siehe Kommentar bei vfl-journal-reset-lauf). Frueher stand dieser Reset
+  ;; ERST kurz vor der Hauptschleife (nach Startpunkt/Hoehe/AS-Praeambel) -
+  ;; realer Bug: die bereits aufgezeichnete Praeambel wurde dadurch selbst
+  ;; wieder geloescht, das gespeicherte Journal begann mit dem ERSTEN
+  ;; STEP-Marker statt mit PT (sichtbar als vsp-bau-aus-spec-DESYNC "Token 1:
+  ;; erwartet PT..., gebaut STEP...", betraf ausnahmslos JEDE Kette).
+  (vfl-journal-reset-lauf)
   (princ "\n\n=========================================")
   (princ (ssg-text "vfl-modus1-header"))
   (princ "\n=========================================")
@@ -6120,18 +6130,10 @@
   (setq letzter-typ nil  fertig nil  frame nil)
   (setq anzahl-gf 0  anzahl-vf 0)
   (vfl-acc-reset)
-  ;; *vfl-journal* wurde bisher NIRGENDS zurueckgesetzt (vfl-journal-reset war
-  ;; definiert, aber toter Code) - bei MEHREREN Ketten in derselben BricsCAD-
-  ;; Sitzung blieben die Eintraege der vorigen Kette(n) im globalen Journal
-  ;; stehen und wurden der naechsten Kette per (cons ...) VORANgestellt. Real
-  ;; beobachteter Bug: eine fremde Kette (anderer Test/Bau) landete mit in der
-  ;; XDATA der aktuellen Kette, mit Fehlfunktionen in der Attribut-/XDATA-
-  ;; Erzeugung (u.a. "bad argument type ... at [itoa]"). vfl-journal-reset-
-  ;; lauf statt vfl-journal-reset: NICHT *vfl-replay-queue* mitloeschen -
-  ;; ein REPLAY-getriebener Aufrufer (vsp-bau-aus-spec) hat sie ueber
-  ;; vfl-journal-replay-start bereits VOR diesem Aufruf befuellt (siehe
-  ;; Kommentar bei vfl-journal-reset-lauf).
-  (vfl-journal-reset-lauf)
+  ;; *vfl-journal*-Reset steht jetzt GANZ AM ANFANG der Funktion (vor der
+  ;; Startpunkt/Hoehe/AS-Praeambel) - siehe Kommentar dort. Hier NICHT mehr
+  ;; noetig (und schaedlich: wuerde die bereits aufgezeichnete Praeambel
+  ;; dieses Laufs wieder loeschen).
 
   (while (not fertig)
     ;; --- Naechstes Element bestimmen ---
@@ -8784,6 +8786,14 @@
   (princ (ssg-text "vfl-m3-titel"))
   (princ "\n=========================================")
 
+  ;; *vfl-journal* VOR dem allerersten vfl-in-*-Aufruf zuruecksetzen (nicht
+  ;; *vfl-replay-queue*, siehe Kommentar bei vfl-journal-reset-lauf und die
+  ;; analoge Korrektur in vf-linienzug-modus). Frueher stand dieser Reset erst
+  ;; kurz vor Phase B (nach der Pfadauswahl UND der Startpunkt/Hoehe/AS-
+  ;; Praeambel) und loeschte damit die bereits aufgezeichnete Praeambel dieses
+  ;; Laufs selbst wieder.
+  (vfl-journal-reset-lauf)
+
   ;; --- Debug-Session (Schalter "vfl-modus2", DEFAULT AN) ------------------
   ;; (dbg-schalter-off "vfl-modus2") deaktiviert bei Bedarf. Alle Eingaben
   ;; laufen bereits durchgehend ueber die vfl-in-*-Wrapper (siehe unten) und
@@ -9148,12 +9158,10 @@
   (setq vfl-nummer (vf-next-number))
   (setq lastEnt (vf-lastent-ohne-attribute))
   (vfl-acc-reset)
-  ;; Siehe Kommentar bei vf-linienzug-modus: *vfl-journal* wurde bisher nie
-  ;; zurueckgesetzt und konnte Eintraege einer vorigen Kette (Modus 1 ODER 2)
-  ;; in dieselbe Sitzung hineintragen. vfl-journal-reset-lauf statt
-  ;; vfl-journal-reset: NICHT *vfl-replay-queue* mitloeschen (siehe dortiger
-  ;; Kommentar) - derselbe Grund wie in vf-linienzug-modus.
-  (vfl-journal-reset-lauf)
+  ;; *vfl-journal*-Reset steht jetzt GANZ AM ANFANG der Funktion (vor der
+  ;; Pfadauswahl/Praeambel) - siehe Kommentar dort. Hier NICHT mehr noetig
+  ;; (und schaedlich: wuerde die bereits aufgezeichnete Praeambel dieses
+  ;; Laufs wieder loeschen).
   (setq anzahl-gf 0  anzahl-vf 0  frame nil)
   ;; --- Abbruch-Sicherung ab hier scharf (analog Modus 1, siehe dortiger
   ;; Kommentar) - Phase A (oben) baut noch keine Geometrie, ein Abbruch