Bug: Deployment-Aktionen (Löschen/Redeploy) für alle deaktiviert — owner_id wird nicht geliefert

[Gree44]

Symptom

Auf der Deployment-Detailseite sind alle Aktionen in der „Aktionen"-Card (Löschen/Abbrechen/Aufräumen, seit #192 auch „Neu deployen") deaktiviert — auch für den Nutzer, der das Deployment gerade selbst erstellt hat, und auch für Admins. Tooltip: „nur vom Besitzer ausführbar".

Ursache (zwei getrennte Fehler)

Die Gate-Logik in src/pages/DeploymentDetails.tsx:

canManageDeployment = deployment.ownerId != null && deployment.ownerId === currentUser.userId

ownerId kommt aus backendDeployment.owner_id (src/pages/DeploymentDetailsPage.tsx:542).

Fehler 1 — Backend liefert owner_id nicht.
Das Schema DeploymentResponse (appstore-backend/src/schemas/deployment.py:156) hat kein owner_id-Feld, und weder der Single-GET (src/api/deployments.py:370-410) noch der List-Endpoint patchen es nach. → owner_id ist immer undefined → ownerId immer null → canManageDeployment immer false, für jeden.

Fehler 2 — ID-Raum-Mismatch.
Selbst wenn owner_id geliefert würde: get_deployment_owner_id() (appstore-backend/src/api/deployments.py:40) gibt die lokale DB-User-ID (teacher_user.id) zurück, während das Frontend gegen currentUser.userId = Keycloak-sub vergleicht. Zwei verschiedene ID-Räume — würde nie matchen.

Fix-Vorschlag

• Backend: owner_id im DeploymentResponse ausliefern, als Keycloak-sub (nicht als lokale DB-ID), damit der Frontend-Vergleich gegen token.sub greift. Betrifft GET single + List.
• Frontend: zusätzlich currentUser.isAdmin im Gate berücksichtigen (Admins dürfen laut authorize_deployment_access ohnehin alles managen).

Kontext

Entdeckt bei der Verifikation von #192 (PR #234). Der Redeploy-Code selbst ist korrekt, hängt aber am selben kaputten Gate — daher ist E2E-Test von #192 aktuell blockiert. Dieser Bug ist vorbestehend und unabhängig von #192.

Cross-Repo: Fehler 1 + 2 liegen im Backend (appstore-backend).