fix(orchestrator): aktive Pipeline-Schritte beim Cancel mitschliessen

Beim User-Cancel wurde nur refresh_log auf cancelled gesetzt, der zuletzt
aktive refresh_pipeline_steps-Eintrag blieb verwaist. Der
/api/incidents/<id>/pipeline-Endpoint liefert daraus dauerhaft
"Schritt X laeuft" an die UI, auch lange nach dem Cancel.

- pipeline_tracker.cancel_active_steps(): neuer Bulk-Helper, setzt alle
  noch active-Schritte eines refresh_log_id auf cancelled mit completed_at
- _mark_refresh_cancelled holt die refresh_log_id, macht das refresh_log-
  Update wie bisher und ruft danach cancel_active_steps auf

Reproduziert bei Lage 80 (Bjoern Hoecke), refresh_log 1273. Frontend-
CSS kennt status-cancelled nicht, faellt auf den neutralen Default-Style
zurueck (kein Spinner mehr, kein Haken, korrekt ent-hangen).

src/services/pipeline_tracker.py

@@ -228,3 +228,25 @@ async def error_step(db, ws_manager, *, step_id: Optional[int], refresh_log_id:
         "status": "error",
         "pass_number": pass_number,
     }, visibility, created_by, tenant_id)
+
+
+async def cancel_active_steps(db, *, refresh_log_id: int) -> int:
+    """Schliesst alle noch aktiven Pipeline-Schritte eines Refreshs als 'cancelled' ab.
+
+    Wird vom Orchestrator nach einem User-Cancel aufgerufen. Ohne diesen Schritt
+    bleibt der zuletzt aktive Step-Eintrag verwaist und der Pipeline-Endpoint
+    liefert dauerhaft 'Schritt X laeuft' an die UI.
+    """
+    try:
+        cur = await db.execute(
+            """UPDATE refresh_pipeline_steps
+               SET status = 'cancelled', completed_at = ?
+               WHERE refresh_log_id = ? AND status = 'active'""",
+            (_now_db(), refresh_log_id),
+        )
+        await db.commit()
+        return cur.rowcount or 0
+    except Exception as e:
+        logger.warning(f"Pipeline cancel_active_steps DB-Fehler: {e}")
+        return 0
+