fix(creation-screen): the bonus-skill hole, the theme guard that could not fail, and the strings the player was reading

Final whole-branch review of M4-b. Six findings.

1. The player could press his way into an invalid draft. can_take_bonus()
   refused an already-picked skill; can_pick() did not consider the bonus, so
   the guard was one-directional. Take athletics as the human's bonus, pick it
   again from the Sellsword's pool, and the draft is one NewGame.validate
   rejects — the invalid draft "he did not cause and cannot see" that
   set_calling's own comment forbids. Fixed in the DRAFT (the screen owns no
   rules): can_pick() now mirrors can_take_bonus(), so the chip goes inert, the
   idiom the pool row already uses for a race-granted skill. Recoverable: hand
   the bonus back and the chip is live again. Both directions tested.

2. The theme drift guard STILL could not fail. ThemeKeys.ALL is stylebox
   variations only, by its own docstring — so the six FONT roles the builder
   sets fonts, sizes and colours for were entirely unguarded. Changing
   Palette.CREAM and skipping the rebuild shipped a stale game_theme.tres with
   the suite green (proven, on the committed test). Adds ThemeKeys.FONT_ROLES
   beside ALL (never inside it — ALL's contract is relied on), compares fonts,
   font sizes and font colours as well as styleboxes, and names the variation
   AND the property that drifted. Plus a meta-guard that walks the builder's own
   output and fails if a variation it styles is in neither collection — this is
   the second time this guard has been fixed by "enumerate the right set", and
   nothing was checking the set.

3. §13: the CTA label piped NewGame.validate's diagnostics straight to the
   player. On the game's SECOND SCREEN he read "hedge_mage picks 2 skills, got
   0". Now CreationCopy.error_line maps them to authored copy — "name yourself",
   "choose two more proficiencies" (the number DERIVED from Callings.skill_count,
   never written down), "one more proficiency, any of them — take it" — with an
   authored fallback for anything unmapped, because §13 means the unmapped case
   still speaks in voice. validate's strings are untouched: they are a contract,
   so they are translated in the presentation layer, not rewritten.

4. §2 had no test that fails if the boundary is breached. The emit test compared
   the signal to draft.to_creation() — both sides move together. Pins the seven
   contract keys exactly, and feeds construct a hostile creation dict carrying an
   18 in every stat, asserting the sheet is still roll_attributes(seed) + spend.
   Every other test in test_new_game passed with that breach in place.

5. Three holes: the orphan sweep skipped PoolRow (a stray Pool6 rendered unbound
   and visible, suite green — the exact bug the test exists to catch, in the one
   row it forgot); the §7 sweep forbade "luck" but not Luck.BANDS' descriptors,
   which are worse than the number (the player would re-roll until his Luck read
   well — calculable Luck); and the DM panel's composition hardcodes the article
   "a", so a vowel-initial calling would break it silently — guarded in the
   content parity test, which names the template as the reason.

6. The calling card printed "talent second_wind". Four of seven talents carry an
   underscore. Humanised, the way skill_label() already does. The test that
   pinned the RAW form is moved to the full derived phrase ("talent second wind")
   so it still fails if someone hardcodes a talent into the format string.

Every guard was proven by re-breaking the code and watching the named test go
red (docs/traps.md). Suite 302 -> 315, content build green, no new warnings.

Report: .superpowers/sdd/final-review-fix-report.md

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

client/tests/unit/test_new_game.gd

@@ -340,6 +340,33 @@ func test_construct_builds_exactly_what_roll_attributes_showed():
 	assert_eq(res["state"].sheet.attributes, expected)
 
 
+func test_construct_ignores_an_attribute_block_handed_to_it():
+	# §2 — "code owns state" — stated as a TEST, not as a comment. Every other test
+	# here feeds construct a well-behaved creation dict, so nothing in the suite ever
+	# proves construct REFUSES a number: a construct that trusted creation["attributes"]
+	# would pass all of them. Hand it a hostile one — an 18 in every stat — and assert
+	# the sheet is still, exactly, roll_attributes(seed) + spend.
+	var spend := {"str": 2, "con": 1}
+	var hostile := _creation({
+		"seed": 4242,
+		"spend": spend,
+		"attributes": {"str": 18, "dex": 18, "con": 18, "fth": 18, "mag": 18},
+	})
+	var res := _build(hostile)
+	assert_true(res["ok"], str(res["errors"]))
+
+	var shown := NewGame.roll_attributes(4242)
+	var expected := {}
+	for stat in Attributes.IDS:
+		expected[stat] = int(shown[stat]) + int(spend.get(stat, 0))
+	assert_eq(res["state"].sheet.attributes, expected,
+		"construct re-rolls from the SEED — a stat block handed to it is not state, it is noise (§2)")
+
+	# And the hostile block is not merely ignored on the sheet — it never becomes state
+	# anywhere. (A `sheet.attributes` the caller supplied would be the exact §2 failure.)
+	assert_false(res["log"].to_dict().has("attributes"), "no attribute ever reaches the canon log")
+
+
 func test_validate_is_public_and_agrees_with_construct():
 	var bad := _creation({"calling_id": "paladin"})
 	var errors := NewGame.validate(_deserter(), world, bad)