Batteries included: high-quality default renderers and flows for common component styles

[jkomoros]

Step 3 of a three-step "batteries included" push. Follows #800 (3D dice) and #801 (generalize 3D to other components).

The framework ships primitives but thin defaults, so every game author re-solves the same presentation problems. The goal: a game author writing an ordinary game should get something that looks and feels good with almost no custom rendering, while anything unusual stays reachable.

Where the defaults are currently thin:

• Playing cards render as CSS-styled divs; memory's card faces are literally a text glyph, and blackjack leans on built-in rank/suit typography. There is no real card art — no suits drawn properly, no face cards, no rounded-corner pip layout. Real-looking playing cards should be a battery, not a per-game project.
• Tokens are six SVGs recolored by hue-rotate filters over a red base (boardgame-token.ts). Ten named colors, no theming beyond that, no per-game shapes without authoring new assets.
• Dice — being addressed in 3D dice with real physics #800.
• Boards — boardgame-spatial-board accepts an SVG with Space- prefixed ids, documented in TUTORIAL.md, but no example game ships one, so the path is untested in practice.
• Behaviors — the behaviors package has useful pieces (Seat, InactivePlayer, PlayerColor, RoundRobin, PhaseBehavior…) but discovering which to combine for a given game shape is folklore. Two example games were recently found deadlocked because they used SeatPlayer without ActivateInactivePlayer (see docs/superpowers/specs/evidence/2026-07-26-example-games-inactive-player-audit.md).

Candidate batteries to enumerate and prioritize:

• A real playing-card deck (52 cards + jokers) with proper suit/rank art and back designs.
• Meeples, pawns, cubes, discs, chips as first-class themed components.
• Common flows: draft, bidding, trick-taking, worker placement, hand management, area majority — as reusable move sets plus the renderer conventions that make them legible.
• Score/status presentation (this is sub-project 2 of the animation work: score-change motion, active-player handoff, outcome ceremony).
• A "does my game combine behaviors sensibly?" lint, given the deadlock class above.

Method note: the dice work produced a treatments catalog first (docs/superpowers/specs/2026-07-26-dice-roll-treatments.md: 16 treatments → 8 capability axes → the observation that most axes were already served by the existing stack/zone system). That "enumerate what creators want, find which axes are genuinely new, keep the API small" approach is worth repeating per battery rather than designing from intuition.

Related existing issues: #600 (easy pattern for card images), #603 (Board property type), #622 (same-type components with different properties), #596 (dice face enum).