### feat: implementiere SQLite-Integration und Repository-Refactoring

- Erstelle Persistenz-Layer mit SQLite-Tabellen für `Verein` und `Reiter` inkl. Queries.
- Entferne Mock-Daten in `ReiterViewModel` und nutze Repository-Injektion.
- Integriere neue Tabellen und Queries im `DesktopMasterdataRepository`.
- Erweitere `VeranstalterWizardViewModel` um lokale Suche mit SQLite-Queries.
- Harmonisiere Feldnamen (`remoteReiterResults`) über alle Module hinweg.
- Aktualisiere DI-Module (`VeranstalterModule`, `ReiterModule`, `DesktopModule`) mit SQLite-Injektionen.
- Refaktor UI-Komponenten und Screens (`ReiterScreen`, `StammdatenImportScreen`) mit neuer Logik.

frontend/features/verein-feature/src/jvmMain/kotlin/at/mocode/frontend/features/verein/di/VereinFeatureModule.kt

@@ -1,15 +1,13 @@
 package at.mocode.frontend.features.verein.di
 
-import at.mocode.frontend.features.verein.data.FakeVereinRepository
+import at.mocode.frontend.features.verein.data.KtorVereinRepository
 import at.mocode.frontend.features.verein.domain.VereinRepository
 import at.mocode.frontend.features.verein.presentation.VereinViewModel
 import org.koin.core.module.dsl.viewModelOf
 import org.koin.dsl.module
 
 val vereinFeatureModule = module {
-  // Desktop-App nutzt im Startup-Mode bevorzugt das Fake-Repository
-  // Kann bei Bedarf auf KtorVereinRepository umgestellt werden:
-  // single<VereinRepository> { KtorVereinRepository(get(named("apiClient"))) }
-  single<VereinRepository> { FakeVereinRepository() }
+  // Desktop-App nutzt nun das KtorVereinRepository (API) oder wir könnten ein SQLite Repository bauen
+  single<VereinRepository> { KtorVereinRepository(get()) }
   viewModelOf(::VereinViewModel)
 }