docs(server-tech): ADR für Server-Technologie – Ktor gewählt

Anforderungen/design/server-tech/adr-server-technology.md:
Architecture Decision Record für die Server-Technologie in Phase 2
(Geräte-Synchronisierung). Ktor gewählt wegen gleicher Sprache
(Kotlin), kotlinx.serialization-Kompatibilität, Code-Sharing-
Möglichkeit, geringem Ressourcenverbrauch und JetBrains-Support.

Geprüfte Alternativen: Spring Boot, Node.js+Express, Python+FastAPI.

Closes #10

Anforderungen/design/server-tech/adr-server-technology.md

@@ -0,0 +1,56 @@
+# ADR: Server-Technologie für Geräte-Synchronisierung
+
+**Status:** Akzeptiert
+**Datum:** 2026-05-14
+**Issue:** #10
+
+---
+
+## Kontext
+
+Die Krisenvorrat-App (Android/Kotlin) benötigt in Phase 2 einen REST-Server für die Synchronisierung und das Sharing des Inventars zwischen mehreren Geräten. Der Server wird im privaten Umfeld eingesetzt (2–10 Geräte, wenig Last) und soll einfach auf einem kleinen Linux-VPS oder Homeserver deploybar sein.
+
+Das bestehende Client-Datenmodell nutzt kotlinx.serialization für JSON-Export/Import.
+
+## Entscheidung
+
+**Gewählt: Ktor** (Kotlin-nativer Server von JetBrains)
+
+## Begründung
+
+1. **Gleiche Sprache wie der Client:** Ktor ist in Kotlin geschrieben und ermöglicht die direkte Wiederverwendung von Datenmodellen (`@Serializable`-Klassen) zwischen Android-Client und Server – idealerweise in einem Shared-Modul.
+
+2. **kotlinx.serialization als First-Class-Citizen:** Das bestehende Client-Datenmodell nutzt bereits kotlinx.serialization. Ktor unterstützt dies nativ, sodass keine zusätzliche Serialisierungs-Bibliothek (wie Jackson bei Spring Boot) nötig ist.
+
+3. **Koroutinen-basiert:** Konsistent mit dem Android-Client, der ebenfalls Kotlin Coroutines verwendet. Gleiche Konzepte, gleiche Patterns.
+
+4. **Leichtgewichtig:** Start in unter 1 Sekunde, geringer RAM-Verbrauch. Kein Application-Server nötig (eingebetteter Netty/CIO). Ideal für den geplanten Einsatz auf einem kleinen VPS oder Homeserver.
+
+5. **JetBrains-Support:** Langfristige Pflege durch JetBrains gesichert. Monatliche Releases, aktive Weiterentwicklung (aktuell Version 3.x).
+
+6. **Modulares Plugin-System:** Nur einbinden was man braucht – kein unnötiger Overhead.
+
+## Geprüfte Alternativen
+
+### Spring Boot (Score: 6/10)
+
+- **Pro:** Industriestandard, riesige Community, umfangreiches Ökosystem
+- **Contra:** Java-First (Kotlin ist Second-Class-Citizen), hoher Overhead (RAM, Startzeit) für ein kleines Projekt, kotlinx.serialization nicht nativ unterstützt (Jackson bevorzugt), keine direkte Wiederverwendung der Client-Datenmodelle
+
+### Node.js + Express (Score: 5/10)
+
+- **Pro:** Leichtgewichtig, schnelles Prototyping, große Community
+- **Contra:** Sprachwechsel Kotlin ↔ JavaScript, kein Code-Sharing möglich, doppelte Modell-Definition nötig, npm Supply-Chain-Risiken
+
+### Python + FastAPI (Score: 5/10)
+
+- **Pro:** Schnelle Entwicklung, automatische OpenAPI-Doku, async I/O
+- **Contra:** Sprachwechsel Kotlin ↔ Python, kein Code-Sharing, andere Toolchain, fragiles Deployment (venv/pip)
+
+## Konsequenzen
+
+- Der Server wird als Kotlin/Ktor-Projekt aufgesetzt
+- Datenmodelle können in einem Shared-Modul zwischen Client und Server geteilt werden
+- kotlinx.serialization wird sowohl auf Client- als auch Server-Seite verwendet
+- Exposed ORM wird für die Datenbankanbindung evaluiert
+- Deployment als Fat JAR oder Docker-Container