feat(build): Refactor infrastructure modules and establish single source of truth

This commit introduces a major refactoring of the build system and the core infrastructure modules. The primary goal is to establish a strict "Single Source of Truth" for all dependencies using Gradle Version Catalogs and to create a clean, maintainable, and scalable foundation for all current and future services.

### 1. Centralized Dependency Management (`libs.versions.toml`)

- **Established Single Source of Truth:** All dependency versions are now exclusively managed in `gradle/libs.versions.toml`. Hardcoded versions have been removed from all build scripts.
- **Introduced Gradle Bundles:** To simplify module dependencies, several bundles have been created (e.g., `testing-jvm`, `redis-cache`, `spring-cloud-gateway`, `monitoring-client`). This drastically reduces boilerplate in the `build.gradle.kts` files and improves readability.
- **Cleaned up Aliases:** All library and plugin aliases have been standardized for consistency.

### 2. Infrastructure Module Refactoring

All infrastructure modules (`core`, `platform`, `auth`, `cache`, `event-store`, `messaging`, `monitoring`, `gateway`) have been refactored to align with the new dependency management strategy.

- **Simplified Build Scripts:** The `build.gradle.kts` for each module now uses the new bundles and aliases, making them significantly cleaner and easier to understand.
- **Consistent Structure:** The architecture of each module now clearly follows the Port-Adapter pattern where applicable (e.g., `cache-api`/`redis-cache`).
- **Standardized `platform-bom`:** The project's own Bill of Materials (`platform-bom`) now also includes the Spring Cloud BOM, ensuring version consistency for all Spring-related dependencies.

### 3. Added Infrastructure Documentation

To improve onboarding and architectural understanding, a dedicated `README-*.md` file has been created for each refactored infrastructure module:
- `README-CORE.md`
- `README-PLATFORM.md`
- `README-INFRA-AUTH.md`
- `README-INFRA-CACHE.md`
- `README-INFRA-EVENT-STORE.md`
- `README-INFRA-MESSAGING.md`
- `README-INFRA-MONITORING.md`
- `README-INFRA-GATEWAY.md`

These documents explain the purpose, architecture, and usage of each component within the system. This lays the groundwork for our "Tracer Bullet" development approach.

docs/entwickungszyklus/Tracer-Bullet_Checkliste.md

@@ -0,0 +1,94 @@
+✅ TODO-Checkliste: Architektur-Validierung ("Tracer Bullet")
+Phase 1: Backend-Infrastruktur vorbereiten
+[ ] Gradle-Setup bereinigen:
+
+[ ] In settings.gradle.kts sicherstellen, dass nur die platform-, core- und infrastructure-Module aktiv sind. Alle anderen (fachliche Services, Clients) müssen auskommentiert sein.
+
+[ ] Konfiguration finalisieren:
+
+[ ] Die AppConfig.kt mithilfe von Erweiterungsfunktionen (wie in PropertiesExtensions.kt) bereinigen, um Boilerplate-Code zu reduzieren.
+
+[ ] Die Konfiguration um advertisedHost für den ServerConfig erweitern.
+
+[ ] Logging-Infrastruktur implementieren:
+
+[ ] Eine Logging-Bibliothek (z.B. SLF4J mit Logback) zu den platform-Abhängigkeiten hinzufügen.
+
+[ ] Alle println-Aufrufe, insbesondere in ServiceRegistration.kt, durch strukturierte Logger-Aufrufe (logger.info, logger.error) ersetzen.
+
+[ ] Gateway starten und testen:
+
+[ ] Sicherstellen, dass der :infrastructure:gateway-Service gestartet werden kann.
+
+Phase 2: "Ping-Service" als Test-Modul erstellen
+[ ] Modul in Gradle anlegen:
+
+[ ] In settings.gradle.kts eine neue Zeile hinzufügen: include(":temp:ping-service").
+
+[ ] Ein build.gradle.kts für das neue Modul erstellen. Es benötigt Abhängigkeiten zu :core:core-utils und einem Web-Framework (z.B. Spring Boot, wie es im :masterdata-service verwendet wird).
+
+[ ] Service-Implementierung:
+
+[ ] Einen PingController mit einem GET /ping Endpunkt erstellen.
+
+[ ] Die Endpunkt-Logik soll ein einfaches JSON zurückgeben, z.B. {"status": "pong", "timestamp": "..."}.
+
+[ ] Einen logger.info("Ping endpoint called")-Aufruf in die Methode einfügen.
+
+[ ] Service-Anwendung erstellen:
+
+[ ] Eine main-Funktion für den Service erstellen, die:
+
+[ ] Die AppConfig lädt.
+
+[ ] Den ServiceRegistrar initialisiert und den Service bei Consul registriert.
+
+[ ] Den eingebetteten Web-Server startet.
+
+Phase 3: Minimalen Client für den Test anbinden
+[ ] Client-Modul in Gradle aktivieren:
+
+[ ] Den Kommentar für :client:web-app in settings.gradle.kts entfernen.
+
+[ ] UI-Implementierung:
+
+[ ] Eine einfache Seite in der Web-App erstellen.
+
+[ ] Einen Button mit der Aufschrift "Ping Backend" hinzufügen.
+
+[ ] Client-Logik:
+
+[ ] Eine Funktion implementieren, die bei Klick auf den Button einen HTTP-Request an das Gateway sendet (z.B. http://localhost:GATEWAY_PORT/ping).
+
+[ ] Die Antwort des Backends entgegennehmen und den status-Wert ("pong") auf der Seite anzeigen.
+
+Phase 4: Gesamtsystem testen und aufräumen
+[ ] Systemstart:
+
+[ ] Die Docker-Infrastruktur starten: docker-compose up -d.
+
+[ ] Den :infrastructure:gateway-Service starten.
+
+[ ] Den :temp:ping-service starten.
+
+[ ] Den :client:web-app-Service starten.
+
+[ ] End-to-End-Test:
+
+[ ] Die Web-App im Browser öffnen.
+
+[ ] Auf den "Ping Backend"-Button klicken.
+
+[ ] Erwartetes Ergebnis: Die Seite zeigt "pong" an.
+
+[ ] Validierung:
+
+[ ] Im Consul UI (üblicherweise http://localhost:8500) prüfen, ob der ping-service korrekt registriert ist.
+
+[ ] Die Logs des Gateways und des ping-service auf die erwarteten Log-Meldungen überprüfen.
+
+[ ] Aufräumen:
+
+[ ] Wenn alles funktioniert, den aktuellen Stand in Git committen (z.B. "feat: Add stable infrastructure baseline").
+
+[ ] Das :temp:ping-service-Modul und das :client:web-app-Modul in settings.gradle.kts wieder auskommentieren, um den Boden für den ersten echten Fach-Service vorzubereiten.