One person, one name: the name you set in one game is the name the other offers #267

There are two boards now (#265) and one person in front of them. The shooter's menu asks for a name and stores it under its own key; the range's page asks again — "the name your runs go on the board under" — and stores its own. Play both and you are two people, or the same person typing the same name twice; the server, which already gives every visitor a session and a signed-in identity where the forge provides one, knows they are one.

Done looks like

• [ ] A name typed in one game is the name the other offers: one stored value for the visitor, read by every game's page, with each game free to override it for that game if a person wants to.
• [ ] It goes through the settings module #73 introduces — one prefix, one shape, one validation — rather than a third localStorage key with its own rules.
• [ ] A signed-in visitor's name still comes from the forge and is not editable in either game, exactly as today; this is about the guest's name.
• [ ] Changing it in one place does not rewrite history: rows already posted keep the name they were posted under, and the pull says so plainly.
• [ ] Tests would fail without this: a name stored by the shooter appears in the range's field on a fresh load, junk in storage yields the default in both, and a signed-in visitor sees their forge name in both.

Files I expect to change

src/client/main.ts, src/range/main.ts, src/client/settings.ts (from #73), src/pages/game.ts and src/pages/range.ts if the field's default is rendered, and the tests beside each.

Risks

• It waits for #73, which is where a stored value is decided once; without it this adds a fourth key with a fourth idea of what is valid.
• Do not unify the boards. A run and a match are different things and #265 was right to rank them apart; this is about who you are, not what you did.

Suggested: Vesper — it is the visitor's experience across three pages.