# Spec: Admin-Übersichten erweitern — Alle Mitgliedschaften & Alle Benutzer

## Zusammenfassung

Erweitere die beiden Admin-Seiten im EEG Portal, sodass Admins nicht nur ausstehende Anträge, sondern alle Mitgliedschaften und alle Benutzer mit Status-Filtern einsehen können.

## Ausgangslage

Zwei Admin-Seiten zeigen derzeit nur eingeschränkte Daten:

| Seite | Route | Aktueller Inhalt |
|-------|-------|-----------------|
| Admin-Mitgliedschaften | `/dashboard/admin-memberships` | Nur PENDING-Anträge mit Genehmigen/Ablehnen |
| Admin-Benutzerverwaltung | `/dashboard/approvals` | Nur PENDING+verifizierte User mit Freigeben/Ablehnen |

## Ziel

Admin sieht: (1) Alle Mitgliedschaften mit Status-Filter (Ausstehend / Aktive / Alle), (2) Alle Benutzer mit Status-Übersicht (Ausstehende / Alle).

## Anforderungen

### Backend

1. **Neuer Endpoint `GET /api/community/admin/memberships`** — Gibt alle Mitgliedschaften (PENDING, ACTIVE, INACTIVE) zurück. Gleiche DTO-Struktur wie `PendingMembershipResponse` (inkl. validFrom/validTo).
2. **Neuer Endpoint `GET /api/admin/users`** — Gibt alle registrierten Benutzer zurück. DTO: `UserProfileResponse` (bereits vorhanden).
3. **User-Entity erweitern** — `createdAt` (LocalDateTime) Feld hinzufügen für Sortierung nach Registrierungszeitpunkt. Wird in `AuthService.register()` gesetzt. `ddl-auto: update` erstellt die Spalte automatisch.
4. Bestehende `/pending`-Endpoints bleiben unverändert (Abwärtskompatibilität).

### Frontend

5. **Admin-Mitgliedschaften** — Tab-Navigation: "Ausstehende Anträge" | "Aktive Mitgliedschaften" | "Alle". Tab "Ausstehende" behält bestehende Karten-Ansicht. Tabs "Aktive" und "Alle" zeigen Tabellen-Ansicht.
6. **Admin-Benutzerverwaltung** — Tab-Navigation: "Ausstehende Anträge" | "Alle Benutzer". Tab "Ausstehende" behält bestehende Tabelle. Tab "Alle" zeigt Tabelle mit Status-Badges.
7. **Status-Anzeige (user-friendly)** — Technische Enums werden übersetzt:

| Entity | Technischer Status | Anzeige |
|--------|-------------------|---------|
| Membership | PENDING | "Ausstehend" |
| Membership | ACTIVE | "Aktiv" |
| Membership | INACTIVE | "Inaktiv" |
| User | PENDING | "Ausstehend" |
| User | APPROVED | "Freigeschaltet" |
| User | REJECTED | "Abgelehnt" |

8. Client-seitige Filterung (einmal alle Daten laden, Tabs per Signal filtern).

### Nicht im Scope

- Keine Paginierung (Datenmengen sind klein)
- Keine Server-seitige Filterung
- Keine Änderung an bestehenden Admin-Workflows (Genehmigen/Ablehnen)
- Keine Rollenverwaltung

## Technische Details

### MembershipService — getAllMemberships()

Nutzt `MembershipRepository.findAllWithDetails()` mit JOIN FETCH (gleiche Struktur wie `findPendingWithDetails()`, aber ohne WHERE-Clause auf Status). Anschließend gleiche User-Lookup-Logik wie `getPendingMemberships()`.

### PendingMembershipResponse — Erweiterung

Das bestehende DTO `PendingMembershipResponse` wird um `validFrom` und `validTo` erweitert. Da es ein Java record ist, müssen beide Felder hinzugefügt werden — der bestehende `getPendingMemberships()`-Code muss entsprechend angepasst werden.

### UserMapper — Mapping für UserProfileResponse

`UserMapper.mapToDto()` mappt `User` → `UserProfileResponse`. Das `createdAt`-Feld wird nicht ins DTO aufgenommen (nur für Server-seitige Sortierung).

## Akzeptanzkriterien

- [ ] `GET /api/community/admin/memberships` gibt alle Mitgliedschaften zurück (PENDING, ACTIVE, INACTIVE)
- [ ] `GET /api/admin/users` gibt alle Benutzer zurück (PENDING, APPROVED, REJECTED)
- [ ] Admin-Mitgliedschaften-Seite zeigt Tabs "Ausstehende | Aktive | Alle"
- [ ] Admin-Benutzerverwaltung-Seite zeigt Tabs "Ausstehende | Alle"
- [ ] Genehmigen/Ablehnen funktioniert weiterhin auf dem "Ausstehende"-Tab
- [ ] Status-Badges werden korrekt angezeigt (gelb=ausstehend, grün=aktiv/freigeschaltet, rot=inaktiv/abgelehnt)
- [ ] Bestehende REST-API Tests weiterhin bestehen
- [ ] Conventional Commits werden verwendet