Website template's saved game state collides across games and drops writes #20

The Vite template persists the simulator's saved state (MakeCode settings, such as high scores) in a way that loses data in two cases.

Relevant code: App.tsx, lines 17–20 and 48–50,`` lines 119–134``` and line 202.````

1. One storage key for every game. State is read from and written to localStorage under the fixed key "simState". localStorage is per origin, so games hosted on the same origin overwrite each other's saved state. For example, user.github.io/game-a/ and user.github.io/game-b/ share one origin, and the static output now supports subfolders (base: "./").

2. Lost writes on rapid setstate messages. The setstate handler builds the new state from the simState captured in its closure (setSimState({...simState, [key]: value})). The message listener is only re-registered by the effect after React commits ([simState] dependency, line 202). Two setstate messages handled before that commit, such as a game writing two settings in a row, both start from the same old simState, and the second overwrites the first.

Found by reading the code; not reproduced in a browser.

This matters for the save-state roadmap item: the Electron and Tauri outputs will load this same site.

Expected behavior: the storage key is namespaced per game, for example by path_friendly_name filled in at build time. The handler uses a functional update, setSimState(prev => ({...prev, [key]: value})), so every write is kept.

Found while reviewing PR #7, toolchain at ce12c48.