API: Die Job-Kette existiert jetzt — POST /jobs, Watcher, Postgres, /logs

Vorher gab es KEINEN Code-Pfad, der je einen Rip ausgelöst hat: kein
POST /jobs, kein udev-Daemon (udev_daemon.py existierte nirgends), GET /jobs
gab hart [] zurück, Postgres lag komplett brach, der SSE-Stream konnte
strukturell nie senden (sse_connections wurde nie befüllt), udevadm lieferte
ohne udevd nichts.

- POST /jobs: legt Job-Zeile an, schickt worker.tasks.rip_disc via Celery
- GET /jobs aus Postgres (running→processing fürs UI)
- Disc-Watcher: 3s-ioctl-Poll statt udev, protokolliert Einwurf/Auswurf
- /devices über /sys (vendor/model) + ioctl-Status — ehrlich statt leer
- /logs + /settings (Settings-Seite sprach vorher gegen 404)
- SSE-Fix, udev aus dem API-Image entfernt, Import-Smoke-Test

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docker/api/celery_client.py

@@ -0,0 +1,20 @@
+"""Dünner Celery-Client: die API SCHICKT Tasks an den Worker, führt sie nie aus.
+
+Bis 23.07. gab es überhaupt keinen Code-Pfad, der je einen Rip auslöste —
+kein POST /jobs, kein udev-Daemon. Dieser Client schließt die Lücke.
+"""
+
+import os
+
+from celery import Celery
+
+REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379/0")
+
+celery_client = Celery("rippy_api", broker=REDIS_URL, backend=REDIS_URL)
+
+
+def start_rip(device_path: str, job_id: str):
+    """Schickt den Rip-Task an den Worker (Task-Name aus worker/tasks.py)."""
+    return celery_client.send_task(
+        "worker.tasks.rip_disc", args=[device_path, job_id]
+    )