fix(creation-model): migrate stray class_id/allowed_classes copies

The canon-log schema and NewGame code already migrated to race_id/
calling_id + allowed_callings, but two copies of the roster outside
that schema were missed, and no parity test guards them:

- docs/canon-log.md (the cross-boundary contract doc) still documented
  the OLD player shape and allowed_classes. Anyone building a player
  block from the doc would get a 422.
- .claude/skills/world-building's schema reference still emitted
  allowed_classes with two dead calling ids (assassin, priest). Author
  a new origin with that skill and it fails origin.schema.json
  (additionalProperties: false, allowed_callings required) AND, if that
  ever loosened, silently allows zero callings at runtime.

Also:
- add schema tests rejecting a dead class_id field and an unknown
  calling_id (priest)
- guard NewGame._validate's container types (spend/skills) so a
  malformed JSON round-trip (null spend, string skills) produces a
  front-loaded error list instead of a GDScript runtime crash
- extend the no-mechanics-in-content test to db.races, not just
  db.callings
- rewrite the roadmap's M4 bullet: the two contract migrations landed;
  only the creation screen and title->creation->shell flow remain

client: 250/250. api: 74 passed, 2 skipped. content_build --check: clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QYa9u7Kdxv5gX4AnwWexy8

docs/canon-log.md

@@ -27,7 +27,7 @@ Full field rules live in `canon-log.schema.json`. Summary:
 ```json
 {
   "schema_version": 1,
-  "player":   { "name": "…", "class_id": "sellsword|assassin|priest", "luck_descriptor": "…" },
+  "player":   { "name": "…", "race_id": "human|elf|dwarf|beastfolk", "calling_id": "sellsword|reaver|cutpurse|trapper|hedge_mage|bonesetter|bloodsworn", "luck_descriptor": "…" },
   "location": { "id": "…", "name": "…" },
   "party":    [ { "id": "…", "name": "…", "disposition": -100..100 } ],
   "recent_events":     ["… (≤5, rolling)"],
@@ -39,9 +39,13 @@ Full field rules live in `canon-log.schema.json`. Summary:
 
 **The §7 boundary (enforced structurally).** The schema sets
 `additionalProperties: false` on the root and on `player`, and `player` admits
-only `name`, `class_id`, `luck_descriptor`. **Numeric Luck, stats, HP/MP, and
-inventory cannot be represented in the canon log** — the AI never sees a number
-it could use to calculate Luck. Only `luck_descriptor` (e.g. "Fortune spits on
+only `name`, `race_id`, `calling_id`, `luck_descriptor`. `race_id` and
+`calling_id` are there so the Narrator and NPCs can *describe* the player (a
+"beastfolk cutpurse" reads different scene text than a "dwarf bonesetter") —
+they are identity for prose, not mechanics. **Numeric Luck, stats, HP/MP, and
+inventory cannot be represented in the canon log** — the mechanical sheet stays
+in `GameState` and never reaches the log, and the AI never sees a number it
+could use to calculate Luck. Only `luck_descriptor` (e.g. "Fortune spits on
 you") crosses the boundary.
 
 All string ids match `^[a-z0-9_]+$`.
@@ -59,7 +63,7 @@ Full rules in `origin.schema.json`. An origin seeds the initial log:
   "disposition_overrides": { "<npc_id>": -100..100 },
   "inventory_grants": [ { "item_id": "…", "qty": 1.. } ],
   "start_quest_id": "…|null",
-  "build_constraints": { "allowed_classes": ["sellsword",…], "luck_modifier": 0 }
+  "build_constraints": { "allowed_callings": ["sellsword",…], "luck_modifier": 0 }
 }
 ```
 

docs/roadmap.md

@@ -75,7 +75,9 @@ Each screen is recreated as a Godot 4.7 Control-node scene against the mockups (
 
 ### M4 — Character creation
 *Content it consumes → [BOM](../content/roadmap.md#2-bill-of-materials): calling blurbs + the Bloodsworn's patron choice (fixed); origins (variable). **~4 pieces.***
-- ○ **Character creation UI** — the mock's screen over our proven model: race + calling cards, six stats with **LCK hidden entirely** (§7), 3d6 floors, the **+3 additive-only spend-up** pool (§8, matches the `character-creation-stats` model), live origin blurb + nameplate. **The class-name reconcile is settled** — all seven callings are named (Sellsword · **Reaver** · Cutpurse · Trapper · Hedge-Mage · Bonesetter · **Bloodsworn**; [races/classes spec](superpowers/specs/2026-07-11-races-and-classes-design.md) §4). Feeds new-game canon-log construction (already built). **Two contract migrations land here, not silently:** the canon log gains a `race` field (the Narrator needs it to describe the player), and `content/origins/deserter.json` still carries the dead `allowed_classes: ["sellsword","assassin","priest"]`. **⛨ saga:** `NewGame.construct` takes `creation` as a plain `Dictionary` — keep it that way. The creation *scene* produces that dict but must not become the only thing that can (a saga synthesizes it and skips the UI). Emit `race_id` + `calling_id` into it. *§2: state · depends on the creation model (M0) + Theme · goal: build a character.*
+- ✅ **Contract migration** — the two contract migrations this milestone owed have **landed**: the canon log's `player` block is now `{name, race_id, calling_id, luck_descriptor}` (the Narrator/NPCs describe the player as e.g. "a beastfolk cutpurse"), and an origin's build-constraints key is now `allowed_callings` (`content/origins/deserter.json` lists all seven real calling ids; the pre-migration key and its two dead class ids are gone from the codebase). Schemas, docs, fixtures, and the world-building skill's content template all agree.
+- ○ **Character creation UI (M4-b)** — the mock's screen over our proven model: race + calling cards, six stats with **LCK hidden entirely** (§7), 3d6 floors, the **+3 additive-only spend-up** pool (§8, matches the `character-creation-stats` model), live origin blurb + nameplate. **The class-name reconcile is settled** — all seven callings are named (Sellsword · **Reaver** · Cutpurse · Trapper · Hedge-Mage · Bonesetter · **Bloodsworn**; [races/classes spec](superpowers/specs/2026-07-11-races-and-classes-design.md) §4). Feeds new-game canon-log construction (already built, and already emits `race_id` + `calling_id` per the migration above). **⛨ saga:** `NewGame.construct` takes `creation` as a plain `Dictionary` — keep it that way. The creation *scene* produces that dict but must not become the only thing that can (a saga synthesizes it and skips the UI). *§2: state · depends on the creation model (M0) + Theme · goal: build a character.*
+- ○ **Title → creation → shell flow (M4-c)** — wire the title screen's *new game* path into character creation and on into the M3 shell, without hardcoding a `new game → creation → world` linear flow (the saga's fourth entry path, §M3, must still be addable later). *§2: n/a (flow) · depends on M4-b + the Title screen (M3) · goal: a playable start-to-shell loop.*
 
 ### M5 — Tactical combat (gridless)
 *Content it consumes → [BOM](../content/roadmap.md#2-bill-of-materials): abilities for the 3 POC classes (fixed); 1 enemy family (4 units) + boss, **tier 1** (variable per tier). **~15 pieces.***