chore(MP-30): final docs cleanup, adr consolidation & legacy removal

Summary
- **Documentation Cleanup:**
  - ADRs consolidated to `docs/adr/`.
  - C4 diagrams moved to `docs/c4/`.
  - Removed legacy folder `docs/architecture/` and `docs/clients/`.
- **New ADR:** Added `0009-final-kmp-architecture.md` (Accepted).
- **Updates:**
  - `ARCHITECTURE.md` updated with final folder structure (Core Modules).
  - `README.md` links fixed.
- **Verification:**
  - `./gradlew staticAnalysis` -> SUCCESS.
  - Path references checked.

Ref: MP-30

docs/adr/0003-microservices-architecture-de.md

@@ -0,0 +1,91 @@
+# ADR-0003: Microservices-Architektur
+
+## Status
+
+Akzeptiert
+
+## Kontext
+
+Nach der Entscheidung, eine modulare Architektur ([ADR-0001](0001-modular-architecture-de.md)) und Domain-Driven
+Design ([ADR-0002](0002-domain-driven-design-de.md)) zu übernehmen, mussten wir die Deployment-Strategie für unsere
+Module festlegen. Zu den wichtigsten Überlegungen gehörten:
+
+1. Unabhängige Skalierbarkeit verschiedener Teile des Systems
+2. Deployment-Unabhängigkeit, um Teams zu ermöglichen, Änderungen ohne Koordination mit anderen Teams zu veröffentlichen
+3. Technologieunabhängigkeit, um verschiedenen Diensten die Verwendung unterschiedlicher Technologien nach Bedarf zu
+   ermöglichen
+4. Resilienz, um sicherzustellen, dass Ausfälle in einem Teil des Systems nicht das gesamte System beeinträchtigen
+5. Klare Zuständigkeitsgrenzen, die mit den Team-Verantwortlichkeiten übereinstimmen
+
+## Entscheidung
+
+Wir haben uns entschieden, eine Microservices-Architektur zu implementieren, bei der jedes Domänenmodul als separater
+Dienst bereitgestellt wird:
+
+- **masterdata-service**: Verwaltet Stammdaten wie Standorte, Disziplinen usw.
+- **members-service**: Verwaltet Mitgliederregistrierung und -profile
+- **horses-service**: Verwaltet Pferderegistrierung und -informationen
+- **events-service**: Verwaltet Veranstaltungserstellung, -planung und -anmeldungen
+
+Jeder Dienst:
+
+- Hat sein eigenes Datenbankschema
+- Ist unabhängig bereitstellbar
+- Kommuniziert mit anderen Diensten über klar definierte APIs und nachrichtenbasierte Kommunikation
+- Ist für seine eigene Domänenlogik gemäß DDD-Prinzipien verantwortlich
+
+Wir haben auch unterstützende Infrastrukturdienste implementiert:
+
+- **gateway**: API-Gateway für Routing und Authentifizierung
+- **auth**: Authentifizierung- und Autorisierungsdienst (Keycloak)
+- **cache**: Caching-Dienst (Redis)
+- **messaging**: Message Broker für die Kommunikation zwischen Diensten (Kafka)
+- **monitoring**: Überwachung- und Beobachtbarkeitsdienste
+
+## Konsequenzen
+
+### Positive
+
+- **Unabhängige Skalierbarkeit**: Jeder Dienst kann basierend auf seinen spezifischen Lastanforderungen skaliert werden
+- **Deployment-Unabhängigkeit**: Teams können Änderungen an ihren Diensten bereitstellen, ohne sich mit anderen Teams
+  abstimmen zu müssen
+- **Technologieflexibilität**: Verschiedene Dienste können je nach Bedarf unterschiedliche Technologien verwenden
+- **Resilienz**: Ausfälle in einem Dienst beeinträchtigen nicht unbedingt andere
+- **Klare Zuständigkeit**: Jeder Dienst hat klare Zuständigkeitsgrenzen, die mit den Team-Verantwortlichkeiten
+  übereinstimmen
+- **Kleinere Codebasen**: Jeder Dienst hat eine kleinere, fokussierte Codebasis
+
+### Negative
+
+- **Komplexität verteilter Systeme**: Microservices bringen die Herausforderungen verteilter Systeme mit sich
+- **Betrieblicher Mehraufwand**: Mehr Dienste müssen bereitgestellt, überwacht und gewartet werden
+- **Herausforderungen bei der Datenkonsistenz**: Die Aufrechterhaltung der Datenkonsistenz über Dienste hinweg erfordert
+  sorgfältiges Design
+- **Netzwerklatenz**: Die Kommunikation zwischen Diensten fügt Latenz hinzu
+- **Testkomplexität**: End-to-End-Tests werden komplexer
+
+### Neutral
+
+- **Teamorganisation**: Teams müssen um Dienste statt um Features herum organisiert werden
+- **Dokumentationsbedarf**: Dienstschnittstellen und -interaktionen müssen gut dokumentiert sein
+
+## Betrachtete Alternativen
+
+### Modularer Monolith
+
+Wir haben die Implementierung eines modularen Monolithen in Betracht gezogen, bei dem alle Module als eine einzige
+Anwendung bereitgestellt werden, jedoch mit klaren Modulgrenzen. Dies wäre einfacher bereitzustellen gewesen und hätte
+die Herausforderungen verteilter Systeme vermieden, hätte aber nicht die Vorteile der unabhängigen Skalierbarkeit und
+Bereitstellung geboten.
+
+### Service-basierte Architektur
+
+Wir haben eine Dienst-basierte Architektur mit weniger bzw. größeren Diensten in Betracht gezogen, die mehrere
+Domänenbereiche umfassen würden. Dies hätte den betrieblichen Overhead reduziert, aber es schwieriger gemacht, klare
+Domänengrenzen und unabhängige Skalierbarkeit aufrechtzuerhalten.
+
+## Referenzen
+
+- [Microservices von Martin Fowler](https://meldestelle-pro.youtrack.cloud/api/files/526-16?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTE2fFViVXRuTGdXcFhIcFRwdG03ZHlSZEZ5ZEc2MG5VVVB3SGJ4OUFRRG82QlENCg&updated=1762340608616)
+- [Building Microservices von Sam Newman](https://meldestelle-pro.youtrack.cloud/api/files/526-17?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTE3fDdjaXJoZ0NlWlQ1MW9tZ0UwdC1fLVZEZ0pUcFF6QnNScTcxN0Z6YlVUazQNCg&updated=1762340788707)
+- [Microservices Patterns von Chris Richardson](https://meldestelle-pro.youtrack.cloud/api/files/526-20?sign=MTc2MjU2MDAwMDAwMHwyLTF8NTI2LTIwfDM5S08yMXVENmFRa1NPaEROQlR1N1Nvc0lWWUJXU0hCR1JYTVJXSDA2RGcNCg&updated=1762340989301)