README: Schreibzugriffe waehrend des Flatten sind belegt

Gemessen an einem Container, der durchgehend schrieb, waehrend abgekoppelt
wurde:

  64 MB vor dem Flatten geschrieben    -> SHA-256 danach OK
  192 MB waehrend des Flatten          -> SHA-256 danach OK
  12 Schreibvorgaenge im Zeitfenster   19:35:48 - 19:36:10
  Flatten selbst                       19:35:48 - 19:36:11
  Gast durchgehend running

rbd flatten fuellt nur Bloecke auf, die der Klon nicht selbst besitzt - was
der Gast geschrieben hat, gehoert ihm und wird nicht ueberschrieben.

Dazu die Einordnung gegenueber dem Live-Restore des Proxmox Backup Servers:
dort wird im Hintergrund nachgeladen, hier nicht. Der Klon ist von Anfang an
vollstaendig und - weil Copy-on-Write nichts kopiert - unabhaengig von der
Groesse in etwa einer Sekunde fertig. Eine 2-TB-VM wird also nicht erst
stundenlang kopiert, sondern ist sofort in Betrieb.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -639,15 +639,49 @@ setzt sich darüber hinweg.
 Schnell ist es, solange Platz da ist: 13 GB waren im Test in rund 70 Sekunden
 kopiert.
 
-**Die Maschine läuft dabei weiter.** `rbd flatten` ist eine Online-Operation —
-anders als beim Live-Restore des Proxmox Backup Servers wird hier nichts
-nachgeladen: Der Linked Clone liegt im selben Pool und ist aus Sicht des Gastes
-von Sekunde eins an vollständig. `flatten` löst nur die *Abhängigkeit*, nicht
-die Verfügbarkeit. Im Test blieb die VM über den gesamten Vorgang auf
+**Die Maschine läuft dabei weiter — und bleibt voll beschreibbar.** `rbd flatten`
+ist eine Online-Operation. Im Test blieb die VM über den gesamten Vorgang auf
 `qmpstatus: running`, der QEMU-Monitor antwortete durchgehend, und die Uhr auf
 der Konsole lief weiter (10:38 → 10:39, mit sichtbarer Bildschirmanimation) —
 inklusive geladenem RAM-Zustand.
 
+Auch Daten, die **während** des Abkoppelns geschrieben werden, überleben es.
+Gemessen an einem Container, der durchgehend schrieb:
+
+| | |
+|---|---|
+| vor dem Flatten geschrieben | 64 MB Zufallsdaten, SHA-256 danach **OK** |
+| während des Flatten geschrieben | 192 MB Zufallsdaten, SHA-256 danach **OK** |
+| Schreibvorgänge im Zeitfenster | 12, von 19:35:48 bis 19:36:10 (Flatten: 19:35:48–19:36:11) |
+| Zustand des Gastes | durchgehend `running` |
+
+Der Grund: `rbd flatten` füllt nur die Blöcke auf, die der Klon noch **nicht**
+selbst besitzt. Was der Gast bereits geschrieben hat, gehört ihm — und wird
+nicht überschrieben.
+
+### Warum das kein „Live-Restore" ist, sondern besser
+
+Beim Live-Restore des Proxmox Backup Servers liegt das Backup auf einem anderen
+Medium: Die VM startet sofort, holt die Blöcke aber im Hintergrund übers Netz
+nach und läuft bis dahin gebremst.
+
+Hier wird **gar nichts nachgeladen**. Der Klon liegt im selben Pool und ist aus
+Sicht des Gastes von Sekunde eins an vollständig — bei voller Geschwindigkeit.
+Und weil Copy-on-Write nichts kopiert, ist er **unabhängig von der Größe** in
+etwa einer Sekunde fertig:
+
+```
+Klon      ~1 s        egal ob 32 GB oder 2 TB
+Start     Sekunden    mit RAM-Zustand sofort im laufenden Zustand
+Arbeiten  ab jetzt    voll beschreibbar
+flatten   nebenher    optional, im laufenden Betrieb
+```
+
+Bei einer 2-TB-VM wird also nicht stundenlang kopiert und dann gestartet —
+gearbeitet wird ab der ersten Sekunde, das Abkoppeln läuft im Hintergrund mit.
+`flatten` betrifft ausschließlich die *Abhängigkeit* vom Quell-Snapshot, nie
+die Verfügbarkeit.
+
 ### Wenn außerhalb von pvesnap gelöscht wurde — `cleanup`
 
 Wird eine Wiederherstellung in der Proxmox-Oberfläche entfernt statt mit