TRO-JSON v4: Slots je TRO und Staubereiche (jamAreas)

- model: Slot (separator/switch/scanner/drive + Rollen), JamArea (J<Separator>,
  Eingang eines TRO mit allen Vorgaengern), derive_slots, derive_jam_areas;
  Schema sps_skel-tro-v4, v3-Dateien werden weiter gelesen
- scl_context: ein JamEntr je eigenem Staubereich statt je Vorgaenger (wie
  UH01-UH05), Ausgaenge nennen den Staubereich des Nachfolgers
- Golden Files neu erzeugt, Tests fuer Slots/Staubereiche, Doku nachgezogen

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

doc/Klassenhierarchie.md

@@ -70,8 +70,11 @@ lib/model.py                                 [Instanz-Ebene / TRO-JSON]
 ├── TroBase(BaseModel)
 │   └─ definition() --> TroDefinition         (gelesen aus tro_catalog, nicht gespeichert)
 │   └── DerivedTro(TroBase)                   [einzige echte Vererbung im Projekt]
+│       └─ slots: list[Slot]                  (Stellen fuer die Hardwareplanung)
 ├── _Positioned(BaseModel)                    (Mixin: position {x,y,z}, describe_position)
-│   ├── TroBase, TroCandidate
+│   ├── TroBase, TroCandidate, JamArea
+├── Slot(BaseModel)                           (separator1/switch1/scanner1/drive + Rollen)
+├── JamArea(_Positioned)                      (Staubereich J<Sep>: Eingang eines TRO)
 ├── Connection(BaseModel)                     (from/to/kind zwischen zwei TRO-IDs)
 ├── TroCandidate(_Positioned)                 (gemeldete Stelle, an der ein TRO erwartet wird)
 ├── Analysis(BaseModel)
@@ -82,7 +85,8 @@ lib/model.py                                 [Instanz-Ebene / TRO-JSON]
     ├─ tros: list[DerivedTro]
     ├─ boundaries: list[DerivedTro]
     ├─ connections: list[Connection]
-    └─ candidates: list[TroCandidate]
+    ├─ candidates: list[TroCandidate]
+    └─ jam_areas: list[JamArea]               (JSON: jamAreas)
 
 lib/material_flow.py                         [CSV-Rohmodell -> Graph, @dataclass]
 ├── Element                                   (1 CSV-Zeile)
@@ -251,13 +255,14 @@ Kantenarten) → Prüfung gegen den Katalog.
 
 ### `TroDocument` — `lib/model.py`
 
-**Wozu:** Die TRO-JSON `<csv>_tro.json` (Schema `sps_skel-tro-v3`) — die
+**Wozu:** Die TRO-JSON `<csv>_tro.json` (Schema `sps_skel-tro-v4`) — die
 Schnittstelle zwischen Ableitung (`tro_flow --json`) und SCL-Ausgabe
 (`scl_skeleton`). Weil beide Seiten dieselbe Klasse benutzen, kann das Format
 nicht unbemerkt auseinanderlaufen.
 
 **Was passiert darin:** `from_analysis()` macht aus einer `Analysis` ein Dokument
-(Kanten + Kantenarten → `Connection`-Liste). `to_json()` schreibt mit den
+(Kanten + Kantenarten → `Connection`-Liste, je TRO die `slots` aus
+`derive_slots()`, die Staubereiche aus `derive_jam_areas()`). `to_json()` schreibt mit den
 JSON-Aliasen, `from_json()` liest und prüft. `extra="forbid"` sorgt dafür, dass ein
 umbenannter oder falscher Schlüssel als Fehler auffällt statt still einen
 Standardwert zu bekommen; `scl_skeleton.main` meldet bei falschem `schema`
@@ -616,7 +621,7 @@ stehen in der TIA-Gerätekonfiguration, nicht im Tag-Import).
 
 | Daten | SCL-Stelle (Beispiel) | Quelle | Bemerkung |
 |---|---|---|---|
-| Anzahl Ein-/Ausgänge und Zuordnung Exit-Nr ↔ Nachbar | `arInOutJamEntr1`, `arInOutJamExit2..4` | L | je Vorgänger ein Eingang, je Nachfolger/Weichenabgang ein Ausgang (`SclJam`) |
+| Anzahl Ein-/Ausgänge und Zuordnung Exit-Nr ↔ Nachbar | `arInOutJamEntr1`, `arInOutJamExit2..4` | L | ein Eingang je eigenem Staubereich (`TroDocument.jamAreas`, Kennung `J<Separator>`; mehrere Vorgänger fahren in denselben ein), je Nachfolger/Weichenabgang ein Ausgang (`SclJam`) |
 | Gleicher Staubereich auf beiden Seiten einer Kante | Exit von A = Entr von B | L | Identität aus der Topologie |
 | Staubereichs-DB und -Index | `"DB_JamArea0102".stJam0102_1.arCarrier` / `.stData` | K (+ E) | Nummerierung der Staubereiche ist Projektvorgabe |
 | Stausensor je Ausgang | `stInSenJam2 := "DB_Inputs".Sensors["cInBG3243"]` | E | |