fix: give the Setup selection groups radio semantics

[philoserf]

Follow-up to the review finding on #73. Picking a character is one choice of six, not six independent switches — aria-pressed was toggle-button semantics, so assistive technology announced three separately-pressable buttons where it should announce one choice of three.

What changed

Each .card-grid is now role="radiogroup" labelled by its step heading; each card is role="radio" with aria-checked. The substantive part is the keyboard contract that comes with it:

• One tab stop per group via roving tabindex, landing on the current choice — or the first option when nothing is chosen yet.
• Arrows move and select, as the pattern requires: left/up and right/down, wrapping at both ends, plus Home and End.

The wrinkle: selecting re-renders the whole Setup screen, destroying the focused card. Without restoring focus, every arrow press would drop the user to the body. renderSetup now re-focuses by id after each render, and the id is built by a shared cardId(kind, itemId) so the builder and the restoration can't drift.

Verified in the browser

initial            monk:tab0  knight:tab-1  poet:tab-1  aristocrat:tab-1  scholar:tab-1  courtier:tab-1
ArrowRight         → character-knight, CHECKED, tab0 (monk drops to -1)
End                → character-courtier
ArrowRight (wrap)  → character-monk
ArrowLeft  (wrap)  → character-courtier
Home               → character-monk
ArrowDown          → character-knight

groups   [{I. The Character, 6 options, 1 tab stop, 1 checked},
          {II. The Skill,    3 options, 1 tab stop, 1 checked},
          {III. The Scenario, 4 options, 1 tab stop, 1 checked}]

aria-checked matches card--selected on every card: true

Mouse selection and the full setup-to-play flow still work — clicking through all three steps reaches the play screen with The Monk — Illumination unspent.

One thing I could not verify, and a correction

I added .card[role='radio']:focus styling and initially justified it by reporting that programmatic focus doesn't set :focus-visible in Safari. That measurement was invalid — the automated Safari window runs backgrounded, so document.hasFocus() is false and visibilityState is hidden, which means neither :focus nor :focus-visible matches anything regardless of the CSS. document.activeElement was correct throughout; only the pseudo-class matching was unobservable.

So the rule is belt-and-braces rather than a response to an observed failure. It still stands on its merits: the radiogroup pattern needs a visible focus indicator, whether a browser treats a programmatic re-focus as focus-visible is a per-browser heuristic, and a ring on a card the user has just selected costs nothing.

Worth a real look when you next have the app open with a focused window — tab into a group, then arrow through it, and confirm the focus ring is visible.

bun run check:ci clean, 82 tests.