fix: Geräte-Pairing - Schlüssel-Code stimmte nie mit dem angezeigten Code überein

SnapshotService.CreateAndUploadAsync lädt in zwei Schritten hoch: Schritt 1
holt einen Code vom Server, Schritt 2 verschlüsselt den Sync-Schlüssel mit
diesem Code und lädt erneut hoch. SnapshotStore.Store() vergab bei jedem
Aufruf bedingungslos einen neuen Zufallscode - der dem Nutzer am Ende
angezeigte Code war dadurch nie derselbe, mit dem der Schlüssel tatsächlich
verschlüsselt wurde. Jede Kopplung musste deterministisch an der
Schlüssel-Entschlüsselung scheitern.

SnapshotUploadRequest bekommt ein optionales Code-Feld; Store() aktualisiert
bei vorhandenem, passendem Code denselben Eintrag statt einen neuen mit
neuem Code anzulegen. Betrifft LehrerApp.Api - der Server muss neu deployt
werden.

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

TODO.md

@@ -1605,6 +1605,24 @@ die Docker-Verifikation unter 10.2.4 (kein Docker im Entwicklungsstand verfügba
       SDK-Host (`dotnet`/`dotnet.exe`) statt auf die App selbst, ein Neustart ohne Argumente hätte
       dort nur die dotnet-CLI-Hilfe gezeigt statt die App neu zu starten — die ursprünglichen
       Kommandozeilenargumente werden in diesem Fall jetzt erneut mitgegeben.
+
+      **Nachtrag (eigentlicher Bugfix — Codes stimmten nie überein):** Der obige Dialog machte
+      den Fehlschlag zwar sichtbar, aber er trat *immer* auf — auch bei korrekt eingegebenem, noch
+      gültigem Code. Ursache, vom Nutzer selbst bis in den `catch`-Block von `SyncCrypto.
+      DecryptKeyWithCode` zurückverfolgt: `SnapshotService.CreateAndUploadAsync` lädt in zwei
+      Schritten hoch — Schritt 1 (ohne Schlüssel) holt vom Server einen frisch vergebenen Code,
+      Schritt 2 verschlüsselt den Sync-Schlüssel mit *diesem* Code und lädt erneut hoch. Beide
+      Schritte trafen serverseitig auf `SnapshotStore.Store()`, das aber bei **jedem** Aufruf
+      bedingungslos einen neuen `NewCode()` vergab und den vorherigen Eintrag löschte. Der dem
+      Nutzer am Ende angezeigte Code (aus Schritt 2) war damit nie derselbe, mit dem der Schlüssel
+      tatsächlich verschlüsselt wurde (aus Schritt 1) — jede Kopplung musste zwingend an der
+      Schlüssel-Entschlüsselung scheitern, unabhängig von Tippfehlern, Ablaufzeit oder
+      Netzwerkproblemen. Behoben: `SnapshotUploadRequest` bekommt ein optionales `Code`-Feld;
+      `SnapshotStore.Store()` aktualisiert bei vorhandenem, zum Nutzer passendem Code denselben
+      Eintrag (`Col.Update`) statt einen neuen mit neuem Code anzulegen; `CreateAndUploadAsync`
+      reicht den in Schritt 1 erhaltenen Code in Schritt 2 zurück. **Wichtig für den Rollout:**
+      diese Änderung betrifft `LehrerApp.Api` (Server) — ein reines Neubauen des Desktop-Clients
+      reicht nicht, der Server muss neu deployt werden.
 - [ ] **10.3.2** Warnung und Wiederherstellungspfad bei verlorenem Schlüssel.
 - [x] **10.3.3** Prüfen, welche Daten unverschlüsselt über `PlainEventStore` laufen —
       personenbezogene Daten dürfen das nicht. `Grade`/`ExamResult` (beide mit `StudentId` plus