feat(save): Speicherstand als Game-Baum

Autosave beim Betreten einer Etage und beim Beenden, ein Slot, bei Tod
geloescht. Der Save ist der Baum selbst — keine eigenen Save-Structs, die
man zweimal pflegt.

- Kacheln als ASCII-Zeilen wie ein Prefab, nicht 3200 Enum-Eintraege
- atomar geschrieben: tmp plus rename, der einzige Stand ueberlebt einen
  Abbruch
- fremdes Schema wird abgelehnt, die Datei bleibt liegen
- fehlende Mods verwerfen Eintraege, nie den Lauf
- Confirm-Screen vor dem Spiel, wenn der Save Eintraege verloren hat

Fuenf Befunde: die Ereigniswarteschlange gehoert nicht in den Save, die
Feldreihenfolge ist Teil des TOML-Formats, Serialize fuer Floor muss von
Hand, Confirm braucht on_no, und die Rueckfrage galt zuerst auch fuer
Mod-Ladewarnungen.

src/data/registries.rs

@@ -477,6 +477,11 @@ pub struct Registries {
     pub npcs: HashMap<String, Npc>,
     /// Keine Registry — ein Block mit festem Schema, feldweise verschmolzen.
     pub balance: Balance,
+    /// Wer geladen wurde, in Ladereihenfolge. **Einziger Leser ist der
+    /// Save-Kopf** (Ticket 03/09): Er stempelt die Versionen, damit ein
+    /// spaeterer Ladelauf „`meinmod` 1.0.0 → 1.2.0 seit dem Speichern" melden
+    /// kann. Das ist die ganze Bilanz des `version`-Felds.
+    pub mods: Vec<crate::data::save::ModStamp>,
     // TODO(M5+): `quests` (Ticket 08) und `scripts` (Ticket 13).
 }