fix(drawing): zwei stille Wege in den Datenverlust

Feinschliff vor dem Ausrollen, beim Durchlesen mit fremdem Blick gefunden und
beide nachgestellt.

Ein Fehler beim Laden ergab ein leeres Zeichenbrett. fetch wirft bei 404 oder
403 nicht. Der Rumpf {"error":"file not found"} ist gültiges JSON, JSON.parse
gelang, elements war undefined – und die Zeichnung ging leer auf. Sie sah aus,
als wäre sie verloren. Wer dann speichert, macht es wahr. Gegen die laufende
Instanz nachgestellt, bevor ich es behoben habe.

Weiterzeichnen während des Speicherns ging verloren. Der Upload lief mit dem
Stand von Sekunde 0; die Fassungsnummer wurde hinterher aus aktuell.current
gelesen – und das war inzwischen ein anderer Stand. Die neuen Striche galten
als gespeichert, ohne je hochgegangen zu sein, und verschwanden beim Schliessen
ohne Rückfrage. Jetzt wird der Stand einmal festgehalten: Er geht hoch, seine
Nummer wird vermerkt, das Vorschaubild zeigt denselben.

Das Laden steht dafür jetzt in ladeZeichnung() statt im Effekt – der Weg hat
drei Fallen, und zwei enden in verlorener Arbeit; das gehört prüfbar. Vier neue
Tests, unter Mutation nachgewiesen: Ohne die Statusprüfung werden zwei rot.

Bewusst so gelassen: Leserecht fällt erst beim Speichern auf. FileItem trägt
kein Rechtefeld, der Text-Editor verhält sich seit jeher genauso, und das
Zeichenbrett bleibt offen – die Arbeit ist also nicht weg.

Geprüft: 57 Vitest-Tests, alle acht Selbsttest-Suiten grün, alle Go-Pakete
grün, tsc sauber.

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

TESTING.md

@@ -1685,6 +1685,47 @@ Excalidraw ist MIT. draw.io waere die Alternative (Apache-2.0), zielt aber auf
 Flussdiagramme und UML statt auf freies Zeichnen – und bringt eine deutlich
 schwerere Oberflaeche mit.
 
+### Feinschliff: zwei stille Wege in den Datenverlust (30.09.2026)
+
+Beim Durchlesen mit fremdem Blick gefunden, beide nachgestellt.
+
+**Ein Fehler beim Laden ergab ein leeres Zeichenbrett.** `fetch` wirft bei 404
+oder 403 **nicht**. Der Rumpf `{"error":"file not found"}` ist gueltiges JSON,
+`JSON.parse` gelang, `elements` war `undefined` – und die Zeichnung ging leer
+auf. Sie *sah aus*, als waere sie verloren. Wer dann speichert, macht es wahr.
+
+Nachgestellt gegen die laufende Instanz:
+
+    GET /api/v1/files/<erfunden>/download?inline=1
+    Status: 404
+    Rumpf : {"error":"file not found"}
+    JSON.parse gelingt -> ['error']     d.elements -> None
+
+**Weiterzeichnen waehrend des Speicherns gingen verloren.** Der Upload lief mit
+dem Stand von Sekunde 0; die Fassungsnummer wurde hinterher aus
+`aktuell.current` gelesen – und das war inzwischen ein anderer Stand. Die neuen
+Striche galten als gespeichert, ohne je hochgegangen zu sein, und verschwanden
+beim Schliessen ohne Rueckfrage.
+
+Jetzt wird der Stand **einmal festgehalten**: Er geht hoch, seine Nummer wird
+vermerkt, und das Vorschaubild zeigt denselben. Ist inzwischen weitergezeichnet
+worden, steht „Unsaved" sofort wieder da – richtig so.
+
+Das Laden steht dafuer jetzt in `ladeZeichnung()` statt im Effekt: Der Weg hat
+drei Fallen, und zwei enden in verlorener Arbeit – das gehoert pruefbar.
+
+- [x] Vier Tests fuer das Laden, unter Mutation nachgewiesen: Ohne die
+      Statuspruefung werden zwei davon rot.
+
+### Was bewusst so bleibt
+
+**Leserecht faellt erst beim Speichern auf.** `FileItem` traegt kein
+Rechtefeld; die Oberflaeche kann vorher nicht unterscheiden. Wer eine geliehene
+Zeichnung nur lesen darf, kann darin zeichnen und erfaehrt es beim Speichern –
+mit dem Satz des Servers. Das Zeichenbrett bleibt dabei offen, die Arbeit ist
+also nicht weg. Genauso verhaelt sich der Text-Editor seit jeher; es einzeln zu
+loesen hiesse, einen Rechte-Endpunkt nur fuer diesen Fall zu bauen.
+
 ### Drei Nachbesserungen aus dem Testen (29.09.2026)
 
 **„Close without saving?" kam, obwohl gerade gespeichert war.** Der Schalter