[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>

doc/TODO-plan-vf-interactive.md

@@ -434,6 +434,53 @@ Zwei Nacharbeiten aus dem Lauf:
   `(load (strcat (getenv "DXFMAKRO") "/tests/test_vf_spec.lsp"))` - oder
   ueber `SSG_RUN_ALL_TESTS`, wo `vf_spec` inzwischen in `alltests.json` steht.
 
+### 4.7 Aufteilung der Testfaelle (2026-09-03)
+
+Nach dem gruenen `VF_SPEC_BAU`-Lauf gab es zwei Tests, die dieselbe Geometrie
+bauen. Aufgeloest:
+
+| | Aufzeichnungsformat | Spec |
+|---|---|---|
+| Daten | `tests/testdata/hm_recformat.json` (281 Objekte) | `tests/testdata/hundm05.json` (52 Objekte) |
+| Treiber | `tests/test_hm_recformat.lsp`, `TEST_HM_RECFORMAT` | `tests/test_hundm05.lsp`, `TEST_HUNDM05` |
+| pytest | `tests/test_hm_recformat.py` | `tests/test_hundm05.py` |
+| In `alltests.json` | **abgeschaltet** | aktiv |
+
+Der Spec-Test ist damit der routinemaessige Bau-Test; die Spec ist auch die
+Datei, in der weitere Ketten der Anlage nachgetragen werden.
+
+**Warum die Aufzeichnung bleibt** (und nicht durch die Spec ersetzt wird):
+
+1. Sie 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 und die Spec belegt nur noch, dass der Emitter
+   mit sich selbst uebereinstimmt.
+2. Sie prueft eine **andere Invariante**: ihr Journal kommt roh aus der XDATA
+   einer Kundenzeichnung. Damit ist `TEST_HM_RECFORMAT` der einzige Test
+   dafuer, dass ein BESTEHENDER `VF_n`-Block weiter abspielbar ist - also
+   dass Doppelklick-Edit und 2D/3D-Konvertierung an Altbestand funktionieren
+   (I1). Ein spec-gebautes Journal kann das nicht zeigen, es kommt aus dem
+   Uebersetzer. Bei Aenderungen am Journal-Format, an den
+   `vfl-in-*`-Wrappern oder am XDATA-Layout also bewusst einschalten.
+3. Sie **dokumentiert die Frage-Reihenfolge**: jeder Eintrag traegt einen
+   `kommentar`, der die zugehoerige Frage nennt. Die Spec verbirgt den Dialog -
+   das ist ihr Zweck - und kann diese Rolle nicht uebernehmen.
+
+Damit es nur EINEN Code-Pfad gibt, der aus einer Spec Geometrie erzeugt, hat
+`tests/test_hundm05.lsp` keine eigene Bau-Logik: es ruft `vsp-bau-datei` aus
+`Lisp/vf_spec.lsp` - dieselbe Funktion, die auch `c:VF_SPEC_BAU` nutzt. Die
+Ergebnisdatei heisst jetzt nach der Spec-Datei
+(`<basisname>_results.json`), damit Befehl und Testrunner in dieselbe Datei
+schreiben und keine zweite Kopie derselben Ergebnisse entsteht.
+
+Nebenbei behoben: 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 von
+`VF_hundm05_LZ_*` auf `VF_hm_recformat_LZ_*` geaendert - und damit die
+Paarung zwischen den beiden Testlaeufen zerlegt. Jetzt feste Konstante
+`TEST_ID_ANLAGE`.
+
 **Noch offen in Stufe 1**: die Uebersetzer fuer Modus 2 (`pfad-handles` +
 Segmentliste, Abschnitt 4.4) und Modus 3 sind NICHT gebaut - Modus 2 braucht
 laut Reihenfolge (Punkt 11) erst 2-3 echte `"linienzug2"`-Journale als