feat(drives): Windows-Treiber an echter Disc BEWIESEN

WAS: Die Hardware-Schicht des Windows-Treibers ist nicht mehr nur gebaut,
sondern gemessen. Messwerte stehen im Modul-Docstring, der gemessene
BD-50-Wert als Testfall in test_cdrom.py.

GEMESSEN (28.08.2026, LG BU40N extern, Laufwerk G:, echte BD-50):

  drive_status()                 -> 4 (CDS_DISC_OK), sofort
  IOCTL_CDROM_DISK_TYPE          -> DATA_TRACK
  IOCTL_DISK_GET_LENGTH_INFO     -> 48 149 364 736 Bytes = 44,84 GiB
  disc_status()                  -> 101 (CDS_DATA_1)
  detect_disc_type()             -> 'bluray'
  device_info()['status']        -> 'ready'
  device_info()['type']          -> 'bluray'

  auswerfen_versuchen()          -> True, 2,41 s
  drive_status() davor / danach  -> 4 / 1

DIE LETZTE ZEILE IST DER EIGENTLICHE BEWEIS. Der Auswurf haengt nicht am
Rueckgabewert des Steuercodes, sondern am ZUSTAND davor und danach: Die
Disc war drin (4) und ist danach draussen (1). Genau das fehlte in v1
monatelang — dort quittierte das ioctl Erfolg, die Schublade blieb zu, und
im Log stand "Disc ausgeworfen".

Die 44,84 GiB pruefen die Schwelle gleich mit: Eine BD-50 liegt knapp unter
den 55 GiB, ab denen classify() auf 'uhd' geht, und wird korrekt als
'bluray' eingeordnet. Wer die Schwelle senkt, macht aus jeder BD-50 eine
UHD — und Rippy waehlte dann das falsche Kompressions-Preset. Der Testfall
haelt den gemessenen Wert fest.

Offen bleibt allein die Ereignis-Erkennung (WM_DEVICECHANGE) — die wird
erst gebaut.

Nebenbei: Beim Eintragen der Messwerte sind drei echte NUL-Bytes in die
Datei geraten (eine Escape-Ebene im Schreib-Skript verschluckt). Python
lehnt so eine Datei rundheraus ab ("source code string cannot contain null
bytes") — im Binaermodus repariert und gegengeprueft.

GEMESSEN: ruff sauber, 430 Tests gruen + 14 uebersprungen.

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

src/rippy/drives/test_cdrom.py

@@ -54,3 +54,19 @@ def test_uhd_ab_schwelle():
 def test_unbekannter_status():
     assert classify(999, 5 * 1024**3) == "unknown"
     assert classify(0, 0) == "unknown"
+
+
+# ── An echter Hardware gemessen ─────────────────────────────────────────
+def test_gemessene_bd50_wird_als_bluray_eingeordnet():
+    """Kein ausgedachter Wert: Am 28.08.2026 an einer echten BD-50 im
+    LG BU40N gemessen (IOCTL_DISK_GET_LENGTH_INFO unter Windows).
+
+    Der Fall ist der interessanteste an der ganzen Zuordnung, weil er dicht
+    an der UHD-Schwelle liegt: 44,84 GiB gegen 55 GiB. Wer die Schwelle
+    senkt, macht aus jeder BD-50 eine „UHD" — und Rippy waehlte dann das
+    falsche Kompressions-Preset.
+    """
+    gemessen = 48_149_364_736          # Bytes, echte BD-50
+    assert gemessen / 1024**3 < 45     # 44,84 GiB
+    assert classify(CDS_DATA_1, gemessen) == "bluray"
+    assert gemessen < UHD_MIN_BYTES

src/rippy/drives/windows.py

@@ -61,11 +61,34 @@ nichts tut, wäre genau die Sorte Placebo, die in Etappe 19 aufgeräumt wurde.
 Die Konstante steht in `win_ioctl.py` — wer sie je benutzt, muss den Fehlschlag
 sichtbar machen.
 
-**NOCH NICHT gemessen:** das Verhalten MIT eingelegter Disc — also die
-Typ-Erkennung (DVD/BD/UHD über Größe) und der Auswurf einer wirklich
-eingelegten Disc. Bei leerem Laufwerk meldet `CHECK_VERIFY2` vorher wie
-nachher „kein Medium"; der Auswurf gilt damit zu Recht als geglückt, beweist
-aber nicht, dass sich die Schublade bewegt hat.
+**MIT EINGELEGTER DISC gemessen (28.08.2026, dasselbe Laufwerk, BD-50):**
+
+    drive_status()                             -> 4 (CDS_DISC_OK), sofort
+    IOCTL_CDROM_DISK_TYPE                      -> Bytes 02 00 00 00
+                                                  = DATA_TRACK (0x2)
+    IOCTL_DISK_GET_LENGTH_INFO                 -> 48 149 364 736 Bytes
+                                                  = 44,84 GiB
+    disc_status()                              -> 101 (CDS_DATA_1)
+    detect_disc_type()                         -> 'bluray'
+    device_info()['status']                    -> 'ready'
+    device_info()['type']                      -> 'bluray'
+
+    auswerfen_versuchen()                      -> True, 2,41 s
+    drive_status() davor / danach              -> 4 / 1
+
+**Die letzte Zeile ist der eigentliche Beweis.** Der Auswurf wurde nicht am
+Rückgabewert des Steuercodes festgemacht, sondern am ZUSTAND davor und
+danach: Die Disc war drin (4) und ist danach draußen (1). Genau das, was in
+v1 monatelang gefehlt hat — dort quittierte das ioctl Erfolg, die Schublade
+blieb zu, und im Log stand „Disc ausgeworfen".
+
+Die 44,84 GiB prüfen nebenbei die Schwelle mit: Eine BD-50 liegt knapp unter
+den 55 GiB, ab denen `cdrom.classify()` auf `uhd` geht — und wird korrekt als
+`bluray` eingeordnet.
+
+**Damit gilt die Hardware-Schicht dieses Treibers als BEWIESEN**, nicht mehr
+nur als gebaut. Offen bleibt allein die Ereignis-Erkennung
+(`WM_DEVICECHANGE`) — die wird erst gebaut.
 """
 
 import sys