What a player sets is remembered: one settings boundary, and a crosshair that is theirs #294

This repository remembers one thing about a player: cs.name. Everything else they set — look sensitivity, volume, bot difficulty, their key bindings — is chosen again on the menu every visit, and the crosshair is a constant (CROSSHAIR in src/client/palette.ts, one colour, one size).

trevato/cs keeps them, and the part worth taking is not the storage but the boundary: one parseSettings that turns whatever localStorage holds into a value the game can play with, where a missing, malformed, out-of-range or unknown entry falls back to the default and never puts a NaN, an unrecognised string or an unbound action into a match. That is the same rule this repository already applies to everything a browser sends the server; the browser's own disk deserves it too.

In this repository's shape:

• src/client/settings.ts holds the shapes and the defaults and nothing else — what a difficulty does to a bot is src/client/bots.ts's business and what a bound key does is src/bind.ts's, and this file knows neither;
• the bindings it stores are the actions in src/bind.ts, so the one list the touch pads and the bindings table already agree on is the list that persists;
• the crosshair becomes colour, size, gap, thickness and a dot, read by src/client/hud.ts where CROSSHAIR is read today — the crosshair already opens as far as the gun is inaccurate, and that stays;
• the range is a second game with its own settings (src/range/binding.ts), so what is shared is the parse-and-default rule, not one file both import: src/independence.test.ts refuses the shortcut.

Done when: a reload comes back with the sensitivity, volume, difficulty, bindings and crosshair a player set; a hand-broken entry is ignored per field and never crashes a boot; and the settings a match is played under are visible on the page it is played from.