[CHANGE] Nur noch EIN Test baut die HundM-Geometrie: Spec wird TEST_HUNDM05

Nach dem gruenen VF_SPEC_BAU-Lauf bauten zwei Tests dieselben 5 Ketten. Der
Spec-Pfad ist jetzt der routinemaessige Bau-Test, der Aufzeichnungs-Pfad der
abgeschaltete Regressionstest fuer das Journal-Format.

Umbenennungen:
- tests/testdata/vf_spec_hundm05.json -> tests/testdata/hundm05.json
  Die Spec ist das Eingabeformat und die Datei, in der weitere Ketten der
  Anlage nachgetragen werden. spec_ids jetzt VF_hundm05_LZ_* (wie im
  Aufzeichnungs-Protokoll), damit sich die Ergebnisse beider Laeufe paaren
  lassen.
- tests/testdata/hundm05.json -> tests/testdata/hm_recformat.json
  tests/test_hundm05.lsp -> tests/test_hm_recformat.lsp (TEST_HM_RECFORMAT,
  Praefix hmrec:, Export hm_recformat:export-results)
  tests/test_hundm05.py -> tests/test_hm_recformat.py
  In alltests.json auf "disabled": true.

Neu: tests/test_hundm05.lsp (TEST_HUNDM05) baut die Spec - OHNE eigene
Bau-Logik, es ruft vsp-bau-datei aus Lisp/vf_spec.lsp. Damit gibt es genau
einen Code-Pfad, der aus einer Spec Geometrie erzeugt; c:VF_SPEC_BAU nutzt
denselben. tests/test_hundm05.py prueft das Ergebnis (die 9 Tests, die
vorher in test_vf_spec.py standen); test_vf_spec.py ist jetzt reiner
Uebersetzer-Test ohne CAD.

Warum das Aufzeichnungsformat bleibt (Details in
doc/TODO-plan-vf-interactive.md Abschnitt 4.7):
- hm_recformat.json ist die EINZIGE eingecheckte Kopie der Originaldaten
  (data/polylines.dxf ist mit 124 MB per .gitignore ausgeschlossen). Die Spec
  ist daraus abgeleitet; ohne die Aufzeichnung faellt die rechte Seite des
  Rundlauf-Beweises weg.
- Es prueft eine ANDERE Invariante: das Journal kommt roh aus der XDATA einer
  Kundenzeichnung. TEST_HM_RECFORMAT ist damit der einzige Test dafuer, dass
  ein BESTEHENDER VF_n-Block weiter abspielbar ist - also dass
  Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Ein
  spec-gebautes Journal kann das nicht zeigen, es kommt aus dem Uebersetzer.
- Es dokumentiert die Frage-Reihenfolge (kommentar je Eintrag); die Spec
  verbirgt den Dialog, das ist ihr Zweck.

Weitere Anpassungen:
- Ergebnisdatei heisst nach der Spec-Datei (<basisname>_results.json), damit
  Befehl und Testrunner in dieselbe Datei schreiben. Verzeichnis: tests/output
  (Override DXFM_VF_SPEC_OUT); NICHT DXFM_RESULTS - das sind die Sivas-/
  CSV-Exporte, dort landete die Datei ausserhalb des Testbaums.
- Neu *vsp-dim-override* fuer TEST_HUNDM05_2D/_3D: wird je Kette angewandt,
  weil der Abbruch-Handler in vf-linienzug-modus *ssg-ils-dim* zurueck setzt.
- Das Anlagenkuerzel der test_id in lib/vf_journal_export.py kam aus dem
  Namen der Ziel-JSON. Nach der Umbenennung haette eine Regenerierung die ids
  stillschweigend auf VF_hm_recformat_LZ_* geaendert und die Paarung der
  beiden Laeufe zerlegt - jetzt feste Konstante TEST_ID_ANLAGE.
- conftest: hundm05_* Fixtures -> hmrec_* (die Spec-Fixtures stehen in
  tests/test_hundm05.py).

Verifiziert: 98 pytest-Tests gruen (die 9 Ergebnis-Tests warten auf einen
neuen TEST_HUNDM05-Lauf), alle .lsp lint-sauber, Spec-Regenerierung
idempotent, TEST_VF_SPEC in BricsCAD 28 PASS / 0 FAIL.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/testdata/object_data.md

@@ -407,7 +407,7 @@ Dasselbe Protokoll steht produktionsseitig als **XDATA am fertigen
 wiederabspielbar (`vfl-journal-replay-start` + `vf-linienzug-modus`, genutzt
 vom Doppelklick-Editieren). Ein Journal aus einer echten Zeichnung laesst
 sich darum 1:1 in dieses Schema zuruecklesen — genau das tut
-`lib/vf_journal_export.py` (siehe Abschnitt 8, `hundm05.json`). Zwei
+`lib/vf_journal_export.py` (siehe Abschnitt 8, `hm_recformat.json`). Zwei
 Unterschiede zum handgeschriebenen `linienzug_tests.json`:
 
 - Zusaetzlicher Eintragstyp `step` (Glied-Marker aus `vfl-journal-mark`,
@@ -427,7 +427,7 @@ blieb an einem `getpoint` haengen. Mit `*vfl-headless*` = T ist das jetzt ein
 harter Abbruch mit Fundstelle (`vfl-headless-abbruch` -> `*vfl-headless-fehler*`
 nennt Art der Eingabe, Glied-Nummer und Eingabe-Nummer). Die Meldungen der
 geometrisch abgewiesenen Sektionen laufen ueber `vfl-meldung` statt `alert` und
-stehen in `*vfl-meldungen*`, blockieren also nichts mehr. `tests/test_hundm05.lsp`
+stehen in `*vfl-meldungen*`, blockieren also nichts mehr. `tests/test_hm_recformat.lsp`
 schaltet beides ein; die Diagnose landet im Ergebnis-JSON
 (`headless_fehler`, `meldungen`, `prompts`).
 
@@ -615,7 +615,7 @@ Vollstaendiges JSON:
   "endpunkt": [220499.01, 154926.53, 0.0]
 }
 ```
-Einen Treiber dafuer gibt es derzeit nicht mehr: `tests/test_hundm05.lsp`
+Einen Treiber dafuer gibt es derzeit nicht mehr: `tests/test_hm_recformat.lsp`
 spielt seit dem Umbau auf die Linienzug-Journale nur noch Ketten ab (siehe
 Abschnitt 8); der fruehere `hundm05:build-gerade` steht in der Git-Historie.
 
@@ -640,9 +640,18 @@ Abschnitt 8); der fruehere `hundm05:build-gerade` steht in der Git-Historie.
 | Omniflo TV_*/APBW_* | - | **nein** (nicht implementiert, DUMMY) |
 | Separator/Scanner | `ils-insert-sensor` | **nein** (Schleife mit `getpoint`/`pause`) |
 
-## 8. HundM05 — die 5 Linienzuege am Kreisel (`hundm05.json`)
+## 8. HundM05 — die 5 Linienzuege am Kreisel
 
-`tests/testdata/hundm05.json` enthaelt die **Eingabe-Journale der 5
+Zwei Dateien beschreiben dieselben 5 Ketten, in zwei Formaten:
+
+| Datei | Inhalt | Test |
+|---|---|---|
+| `tests/testdata/hm_recformat.json` | die **Aufzeichnung**: rohes Eingabe-Journal aus der XDATA der Kundenzeichnung, als Frage-Antwort-Protokoll | `TEST_HM_RECFORMAT` (in `alltests.json` abgeschaltet) |
+| `tests/testdata/hundm05.json` | die daraus abgeleitete **Spec** (Domaenenwerte statt Menue-Codes, 52 statt 281 Objekte) - hier werden weitere Ketten nachgetragen | `TEST_HUNDM05` |
+
+Die Spec ist das Eingabeformat, die Aufzeichnung die Vorlage, an der sie gemessen wird (Rundlauf-Beweis in `tests/test_vf_spec.py`). Warum beide bleiben: die Aufzeichnung ist die einzige eingecheckte Kopie der Originaldaten (`data/polylines.dxf` ist zu gross fuer das Repo) UND der einzige Test dafuer, dass ein BESTEHENDER `VF_n`-Block weiter abspielbar ist - also dass Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren. Gebaut wird routinemaessig nur noch aus der Spec, damit nicht zweimal dieselbe Geometrie entsteht.
+
+`tests/testdata/hm_recformat.json` enthaelt die **Eingabe-Journale der 5
 VarioFoerderer-Linienzuege** aus `data/polylines.dxf` (die Anlage HundM, ein
 Kreisel mit fuenf daran haengenden Ketten). Quelle ist nicht die gezeichnete
 Geometrie, sondern die XDATA `SSG_VF_EDIT` (Marker `"linienzug"`) an den
@@ -675,7 +684,7 @@ Neu erzeugen:
 
 ```
 python lib/vf_journal_export.py data/polylines.dxf \
-    tests/testdata/hundm05.json --csv results/HundM_export.csv
+    tests/testdata/hm_recformat.json --csv results/HundM_export.csv
 ```
 
 Die frueheren Inhalte (Kreisel/Gefaellestrecke/Sensor-Eintraege aus dem
@@ -690,10 +699,10 @@ Kopf-Objekte verschlucken. Darum steht je Kette ein Kopf-Objekt (traegt
 `linienzug_tests.json`. Der Anlagetyp im Kopf heisst `anlagetyp` und NICHT
 `typ`, damit Kopf und Eingabe unterscheidbar bleiben.
 
-Abgespielt wird das per `tests/test_hundm05.lsp` (`TEST_HUNDM05`,
+Abgespielt wird das per `tests/test_hm_recformat.lsp` (`TEST_HM_RECFORMAT`,
 `TEST_HUNDM05_2D`/`_3D`): der Treiber gruppiert die Objekte
-(`hundm05:gruppiere`), baut daraus das Vorwaerts-Journal
-(`hundm05:eintrag->journal`) und spielt es je Kette ueber
+(`hmrec:gruppiere`), baut daraus das Vorwaerts-Journal
+(`hmrec:eintrag->journal`) und spielt es je Kette ueber
 `vfl-journal-replay-start` + `vf-linienzug-modus` ab — denselben Weg nimmt die
 Produktion beim Editieren/Konvertieren (`vfl-konvertiere-ent`). Bewusst KEINE
 Eingabe-Mocks wie in `test_linienzug.lsp`: ein Mock muesste zu jedem Segment