fix(windows): Zweiter Rip startete waehrend der Kompression ins leere Laufwerk

Der Commander meldete einen Rip-Fehlschlag „bei der Komprimierung", obwohl
der Rip laengst durch war:

    makemkvcon endete mit Code 11 — letzte Meldung:
    Das Öffnen der Disk schlug fehl  — keine MKV-Datei entstanden

Auffaellig war, was FEHLTE: kein „Ursache:". Waere der Geraetepfad schuld
gewesen, stuende dort MSG 2024. Bleibt: kein Datentraeger im Laufwerk.

Der Ablauf dahinter:
  1. Rip fertig → Rippy wirft die Disc aus (Standardeinstellung)
  2. Status wird auf `transcoding` gesetzt — ab hier sagte `has_active_job`
     NEIN, das Laufwerk sei frei; es kennt nur pending/running
  3. Die Disc-Wache sieht beim Auswurf einen Statuswechsel → „eingelegt"
  4. Die Vollautomatik startet einen ZWEITEN Rip — auf ein Laufwerk, dessen
     Schublade gerade herausfaehrt

Der zweite Rip lief in ein leeres Laufwerk. Auf dem Bildschirm sah das aus,
als sei die Kompression gescheitert — sie lief ungestoert weiter.

Drei Aenderungen:

* `store.job_offen` — der weitere Riegel (pending/running/transcoding/
  canceling) fuer die Vollautomatik. `has_active_job` bleibt unveraendert:
  Das fragt „haelt gerade jemand das Laufwerk?", und waehrend der Kompression
  tut das niemand — ein Auswurf von Hand bleibt erlaubt.
* `ripping.disc_fehlt` — vor dem makemkvcon-Start nachsehen, ob ueberhaupt
  eine Disc drin liegt. Statt zwei Minuten Warten und Code 11 gibt es einen
  Satz, den man versteht. Ein FEHLGESCHLAGENER Blick verweigert nichts:
  „ich weiss es nicht" darf nie zu „es geht nicht" werden.
* MSG 5010 in KRITISCHE_CODES — MakeMKVs Sammelmeldung sagt fuer sich nichts.

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

docker/api/test_api_smoke.py

@@ -834,3 +834,49 @@ def test_der_job_start_raeumt_eine_haengende_erkennung_weg():
         quelle = inspect.getsource(main)
     assert 'DISC_CACHE.pop(device_path, None)' in quelle, \
         "beim Job-Start muss eine haengende Erkennungs-Marke weg"
+
+
+# ── Kein zweiter Rip waehrend der Kompression (Befund 29.08.2026) ───────
+#
+# Der Commander: „Der Rip an sich war bereits fertig, bei der komprimierung
+# passiert das" — Fehlertext: „Das Öffnen der Disk schlug fehl".
+#
+# Ablauf dahinter: Rip fertig → Disc ausgeworfen → Status `transcoding`.
+# `has_active_job` kennt nur pending/running und meldete „Laufwerk frei".
+# Die Disc-Wache sah den Auswurf als Statuswechsel, die Vollautomatik startete
+# einen ZWEITEN Rip — in eine Schublade, die gerade herausfuhr.
+
+
+def test_automatik_startet_nicht_waehrend_der_kompression(monkeypatch):
+    import asyncio
+
+    import main
+
+    gestartet = []
+    monkeypatch.setattr(main.db, "get_settings", lambda: {"autoRipStart": True})
+    monkeypatch.setattr(main.db, "job_offen", lambda p: True)   # Job komprimiert
+    monkeypatch.setattr(main.db, "has_active_job", lambda p: False)  # Laufwerk frei
+    monkeypatch.setattr(main, "start_rip", lambda *a, **k: gestartet.append(a))
+    main.DISC_CACHE[r"\.\G:"] = {"title": "Akira"}
+
+    asyncio.run(main._auto_rip_wenn_aktiviert(r"\.\G:"))
+    assert gestartet == [], "waehrend der Kompression faengt die Automatik nichts Neues an"
+
+
+def test_job_offen_zaehlt_die_kompression_mit():
+    from rippy.store import JOB_OFFEN
+
+    assert "transcoding" in JOB_OFFEN, "die Kompression gehoert zum Vorgang"
+    assert "canceling" in JOB_OFFEN, "ein Abbruch ist auch noch nicht durch"
+    assert "completed" not in JOB_OFFEN and "failed" not in JOB_OFFEN
+
+
+def test_auswurf_bleibt_waehrend_der_kompression_erlaubt():
+    """Waechter gegen einen zu breiten Riegel: `has_active_job` fragt „haelt
+    jemand das Laufwerk?" — waehrend der Kompression tut das niemand, die Disc
+    darf raus. Nur die AUTOMATIK haelt sich zurueck."""
+    import inspect
+
+    from rippy import store
+
+    assert "transcoding" not in inspect.getsource(store.has_active_job)