Konsolidierung fehlender Endpunkte für Remote-Backend-Frontend (notwendig vs. wünschenswert)

## Kontext

Bei der Entwicklung eines **Remote-Backend-Frontends** für REDAXO (Control-Plane über API) ist aufgefallen, dass mehrere zentrale Betriebs- und Daten-Endpunkte fehlen.

Im aktuellen Stand sind Core-CRUD-Endpunkte (Structure/Media/Templates/Modules/Users/Clangs/Metainfo) vorhanden, aber für den produktiven Remote-Betrieb fehlen wichtige API-Bausteine.

---

## Notwendig (MVP)

### 1) Addon-Management
- `GET /addons` — Addon-Liste inkl. installed/active Status
- `GET /addons/{id}` — Addon-Details (Version, Requirements, Dependencies)
- `PATCH /addons/{id}/status` — aktivieren/deaktivieren

### 2) Addon Lifecycle
- `POST /addons/{id}/install`
- `POST /addons/{id}/uninstall`
- `POST /addons/{id}/activate`
- `POST /addons/{id}/deactivate`
- `POST /addons/{id}/upgrade`

### 3) Cache-Management
- `GET /cache/status` — Größe/Status/Last-Rebuild
- `DELETE /cache/all`
- `DELETE /cache/{type}` — z. B. `db`, `templates`, `packages`

### 4) System-Information / Betrieb
- `GET /system/info` — PHP/REDAXO/Basisinfos
- `GET /system/disk` — Disk Space
- `GET /system/database` — DB-Größe/Tabellenanzahl
- `GET /system/health` — Basis-Healthcheck

### 5) YForm API (für datengetriebene Remote-Backends essenziell)
- `GET /yform/tables`
- `GET /yform/tables/{table}`
- `GET /yform/tables/{table}/fields`
- `GET /yform/tables/{table}/records`
- `GET /yform/tables/{table}/records/{id}`
- `POST /yform/tables/{table}/records`
- `PATCH /yform/tables/{table}/records/{id}`
- `DELETE /yform/tables/{table}/records/{id}`

---

## Wünschenswert (Ausbau)

### Addon Ops / UX
- `GET /addons/{id}/health` — Readiness/Requirement-Check
- `POST /addons/{id}/setup/check` — Preflight vor Install/Aktivierung
- `GET /addons/{id}/logs` — letzte Install/Update-Logs

### YForm Komfort-Endpunkte
- `GET /yform/tables/{table}/options/{field}` — Select/Choice-Optionen
- `GET /yform/lookups/{table}` — Lightweight-Lookups (id + label)
- `POST /yform/tables/{table}/validate` — Payload validieren ohne Persistenz

### Optional für Betrieb
- Erweiterter Healthcheck mit Teilstatus (`db`, `filesystem`, `cache`, `addons`)
- Einheitliche Betriebs-Metriken für Dashboard-Kacheln

---

## Anforderungen (für alle neuen Endpunkte)

- Einheitliches Response-Schema (wie bestehende API)
- Saubere Fehlercodes (`400`, `403`, `404`, `409`, `422`, `500`)
- Klare Admin-Berechtigung für mutierende Operationen (`POST/PATCH/DELETE`)
- Konsistentes Paging/Sorting/Filtering bei Listen

---

## Warum Priorität

Diese Lücken sind im praktischen Aufbau eines Remote-Backends direkt aufgetreten.
Ohne diese Endpunkte bleibt das Dashboard zwar für Basis-CRUD nutzbar, aber nicht als vollständige Control-Plane für Betrieb, Wartung, Addon-Lifecycle und YForm-Datenmanagement.