feat(zns-importer): add ZNSImportService with tests and REST controller

- Created `ZnsImportService` to handle uploading, parsing, and persisting ZNS data from legacy `.zip` files.
- Introduced corresponding test cases in `ZnsImportServiceTest` for handling edge cases including imports and updates.
- Added REST controller `ZnsImportController` for initiating import jobs and retrieving their status.
- Defined `ZnsImportResult` data structure for reporting results of import operations.
- Established database configuration specific to ZNS importer for development profile.
- Updated utility libraries with `FixedWidthLineReader` for fixed-width string parsing.
- Refactored architecture by placing parser logic in `core:zns-parser` for reuse across backend and Compose Desktop app.

Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>

docs/01_Architecture/MASTER_ROADMAP.md

@@ -141,10 +141,12 @@ und über definierte Schnittstellen kommunizieren.
 
 #### 🧹 Agent: Curator & Lead Architect (ZNS-Importer)
 
-*   [ ] **ZNS-Importer (MVP):** Implementierung des ZNS-Importers für Stammdaten.
+*   [x] **ZNS-Importer (MVP) – Phase 1 & 2:** `core:zns-parser` (KMP), `ZnsLegacyParsers` (alle 4 Dateitypen, CP850),
+    `ZnsImportService` (Orchestrator, ZIP in-memory, Upsert), Unit-Tests grün.
     → Detaillierte Planung: `docs/01_Architecture/Roadmap_ZNS_Importer.md`
-  *   [ ] Backend-Infrastruktur & CP850 Parser (Phase 1)
-  *   [ ] Domain-Mapping & Upsert in DB (Phase 2)
+  *   [x] Backend-Infrastruktur & CP850 Parser (Phase 1 – Parser/Modul)
+  *   [x] Domain-Mapping & Upsert in DB (Phase 2)
+  *   [ ] REST-API & Job-Management (Phase 1 – Controller/Job-Registry)
   *   [ ] Frontend-Integration mit File-Picker & Status-Polling (Phase 3)
 
 ---

docs/01_Architecture/Roadmap_ZNS_Importer.md

@@ -1,6 +1,6 @@
 ---
 type: Roadmap
-status: PLANNED
+status: IN_PROGRESS
 owner: Curator
 last_update: 2026-03-25
 ---
@@ -37,30 +37,31 @@ gesteuert wird und die Daten persistent im Backend (`actor-context`) ablegt.
 
 ### Phase 1: Backend-Infrastruktur & Parsing (👷 Backend Developer)
 
-*   [ ] **API Design:**
+*   [x] **API Design:**
   * `POST /api/v1/import/zns` (Multipart/form-data, nimmt `.zip` oder `.dat` entgegen).
   * Rückgabe: `202 Accepted` mit einer `JobId` (UUID).
   * `GET /api/v1/import/zns/{jobId}/status` (Gibt aktuellen Fortschritt und Statusmeldungen zurück).
-*   [ ] **Job-Management:**
-  * Implementierung einer Thread-sicheren In-Memory-Registry oder einfachen DB-Tabelle für den Import-Status (z. B. "
-    ENTPACKEN", "LADE_VEREINE_40%", "ABGESCHLOSSEN").
-*   [ ] **Unzip-Service:**
-  * Entpacken der übermittelten `ZNS.zip` in ein temporäres Verzeichnis (bzw. in den Speicher).
-*   [ ] **Legacy-Parser (CP850 Fixed-Width):**
-  * Schreiben von robusten Mapping-Funktionen, die die Strings bytegenau auslesen.
-  * Berücksichtigung der Spezifikationen aus `OETO-2026_Meldestelle_Pflichtenheft_V2.4_2021-07-28.md`.
+  * Implementiert in `backend:services:zns-import:zns-import-service` (`ZnsImportController`). ✅
+*   [x] **Job-Management:**
+  * Thread-sichere In-Memory-Registry (`ImportJobRegistry`, `ConcurrentHashMap`) implementiert.
+  * Status-Enum: `AUSSTEHEND`, `ENTPACKEN`, `LADE_VEREINE`, `LADE_REITER`, `LADE_PFERDE`, `LADE_RICHTER`,
+    `ABGESCHLOSSEN`, `FEHLER`. ✅
+*   [x] **Unzip-Service:**
+  * ZIP-Entpackung in-memory implementiert (`ZnsImportService`).
+*   [x] **Legacy-Parser (CP850 Fixed-Width):**
+  * `ZnsLegacyParsers` in `core:zns-parser` (KMP-Modul) implementiert.
+  * Alle 4 Dateitypen (VEREIN01, LIZENZ01, PFERDE01, RICHT01) bytegenau gemappt. 4 Unit-Tests grün.
 
 ### Phase 2: Domain-Mapping & Persistenz (👷 Backend Developer)
 
-*   [ ] **Mapper-Logik:**
-  * Konvertierung der geparsten Legacy-Daten in unsere Domain-Modelle (`DomVerein`, `DomReiter`, `DomPferd`,
-    `DomFunktionaer`).
-  * *Sonderfälle:*
-    * `PFERDE01.dat`: Ausländische Systemnummern ignorieren (keine echten Lebensnummern).
-    * `LIZENZ01.dat`: Sperrlisten-Flag (`S`) korrekt auf das `DomReiter`-Modell mappen.
-*   [ ] **Upsert-Strategie (DB):**
-  * Sicherstellen, dass bei mehrfachem Import keine Duplikate entstehen.
-  * Abgleich über eindeutige ZNS-IDs (Satznummern). `INSERT` bei neuen, `UPDATE` bei bestehenden Datensätzen.
+*   [x] **Mapper-Logik:**
+  * `DomVerein`, `DomReiter`, `DomPferd`, `DomFunktionaer` vollständig gemappt.
+  * *Sonderfälle umgesetzt:*
+    * `PFERDE01.dat`: Ausländische Systemnummern werden ignoriert. ✅
+    * `LIZENZ01.dat`: Sperrlisten-Flag (`S`) korrekt auf `DomReiter` gemappt. ✅
+*   [x] **Upsert-Strategie (DB):**
+  * `ZnsImportService` implementiert find + save Logik (Upsert). 7 Unit-Tests grün.
+  * Fehler pro Zeile werden gesammelt (kein Abbruch bei Einzelfehlern). `ZnsImportResult` mit Zählern & Fehlerlisten.
 
 ### Phase 3: Frontend-Integration (🎨 Frontend Expert)