fix(bogen): vorgemerkte Punkte beim Abschicken verbrauchen

Nach Enter stand unspent_points auf 0, waehrend der Screen den Punkt noch
vorgemerkt hielt — die Anzeige rechnete 0 - 1 auf u32 und stuerzte ab.

Der Screen leert sein Feld, waehrend er das Kommando uebergibt, dazu
saturating_sub an den zwei Lesestellen: unspent_points kann sich auch
unter dem offenen Screen aendern.

Erster UI-Test des Projekts. handle_key ist ohne Terminal aufrufbar, und
sobald ein Screen Zustand haelt, ist die Naht zum Spielzustand eine
Fehlerquelle wie jede andere.

.scratch/rustkeep-1.0/issues/11-ui-geruest-screen-modell.md

@@ -272,3 +272,21 @@ vorbeigeht, testet den Spielablauf nicht.
 **Immer mitgebaut**, nicht hinter `cfg(debug_assertions)`. Das wäre ein `#[cfg]` an der Variante *und*
 an jedem `match` darüber — für ein Spiel, das niemand ausliefert. Ein `#[cfg]` reicht später nach,
 wenn es je einen Release-Build gibt.
+
+### Befund aus M5 — die Naht zwischen Screen-Zustand und Spielzustand
+
+Ticket 11 trennt sauber: Ein Screen fasst `Game` nicht an, er gibt ein `Command` zurück. Der
+Charakterbogen hält seit M5 aber selbst Zustand — die **vorgemerkten** Punkte, die erst mit `Enter`
+abgeschickt werden. Beim Abschicken zieht das Spiel sie ab, der Screen behielt sie: `unspent_points`
+stand auf 0, `pending` auf 1, und die Anzeige rechnete `0 - 1` auf `u32`. Absturz.
+
+Das ist keine Schwäche der Trennung, sondern ihr Preis: Wer Zustand doppelt hält, muss sagen, wann er
+abgeglichen wird. Die Antwort hier ist die einfachste mögliche — **vorgemerkt wird beim Abschicken
+verbraucht**, der Screen leert sein Feld, während er das Kommando übergibt. Dazu `saturating_sub` an
+den zwei Lesestellen, weil `unspent_points` sich auch unter dem offenen Screen ändern kann (ein
+Aufstieg im selben Zug).
+
+Dabei ist der **erste UI-Test** des Projekts entstanden. Bis M5 war `ui/` ungetestet, weil dort
+angeblich nur Anzeige liegt — der Absturz zeigt, dass das nicht stimmt: Sobald ein Screen Zustand hält,
+ist die Naht zum Spielzustand eine Fehlerquelle wie jede andere. `handle_key` ist ohne Terminal
+aufrufbar, der Test kostet zwanzig Zeilen.

.scratch/rustkeep-1.0/map.md

@@ -132,7 +132,7 @@ die Tickets zurückgetragen:
 Der Zugablauf aus **14** hat damit einen siebten Schritt, `Creature` ein Feld `intent`, und die
 Sperrgründe, die `ability_block` ohnehin berechnete, haben einen zweiten Nutzen bekommen.
 
-**M5 — Progression** (`feat/m5-progression`, 64 Tests)
+**M5 — Progression** (`feat/m5-progression`, 65 Tests)
 
 | Zusage | Aus | Befund |
 |---|---|---|
@@ -146,6 +146,11 @@ Sperrgründe, die `ability_block` ohnehin berechnete, haben einen zweiten Nutzen
 | Lebensstand folgt dem Zuwachs an **zwei** Stellen | 15 | **es ist eine** — der Aufstieg ändert `max_health` gar nicht |
 | `luck` = eine Chance auf einen Zusatzzug, auf jeder Tabelle | 16 | **bestätigt**, wirkt dreifach aus einer Formel |
 
+Ein fünfter kam beim Spielen dazu: **11** — der Charakterbogen hält seit M5 selbst Zustand (die
+vorgemerkten Punkte). Beim Abschicken zog das Spiel sie ab, der Screen behielt sie, und die Anzeige
+rechnete `0 - 1` auf `u32`. Daraus der **erste UI-Test** des Projekts: Sobald ein Screen Zustand hält,
+ist die Naht zum Spielzustand eine Fehlerquelle wie jede andere.
+
 Vier Befunde nachgetragen: **15** (`strength` und `constitution` las niemand — zwei der fünf
 Wahlmöglichkeiten taten nichts), **15** (von den zwei Zuwachs-Stellen ist eine beweisbar ein No-op),
 **14/16** (`Rng::chance(0.0)` verbrauchte eine Zahl und verschob den Zufallsstrom — derselbe Seed