Give each running game its own screen, capped at 10 concurrent

Previously every game shared one always-on Xvnc/fluxbox/websockify
desktop, so starting two games at once meant they fought over focus on
the same screen and the same ALSA device. Now:

- server.sh no longer starts a shared desktop at all - it just runs
  setup_server.py. There's no default display anymore.
- start_game() allocates a free display from GAME_DISPLAY_NUMS
  (:90-:99, one per MAX_CONCURRENT_GAMES=10 slot), spins up a fresh
  Xvnc+fluxbox+websockify for it, and launches the game with DISPLAY set
  to that display. All four processes are tracked together per game.
- stop_game() tears down all four; is_running() does the same lazily if
  the game exited on its own (crash/quit), so a slot doesn't stay stuck
  just because nobody clicked Stop.
- Starting past the 10-slot cap is refused with an error shown on that
  game's row instead of silently failing.
- Each running game's row gets its own "Open Screen" link (client-side
  JS, since the port is only known once the game is actually started)
  instead of one global noVNC link.
- run.sh publishes the whole 8090-8099 noVNC port range up front, since
  Docker can't add port mappings to an already-running container.

Verified end-to-end: two different games running concurrently get fully
independent Xvnc/fluxbox/websockify/game process sets and noVNC
endpoints; stopping one leaves the other untouched; the capacity guard
correctly refuses a start at the limit.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NiNnj78HGx1KWyCCo39HSz

TODO.md

@@ -9,10 +9,10 @@
      across `--rm` restarts. 1.6GB -> ~690MB. Container now needs network access to
      `vlda-01` at runtime (not just build time) to install games.
   3. Dropped the auto-download at container startup entirely. `scripts/setup_server.py` is
-     a small stdlib-only HTTP server (started alongside Xvnc/fluxbox/websockify) that serves
-     an HTML page on `${SETUP_PORT}` (`70${DISPLAY_NUM}`, published as `7099` by `run.sh`)
-     listing every `*.zip` on the SMB share with an Installed/Install status per game; the
-     user clicks "Install" to fetch+extract a specific game into `${GAMES_HOME}` on demand.
+     a small stdlib-only HTTP server that serves an HTML page on `${SETUP_PORT}`
+     (`70${DISPLAY_NUM}`, published as `7099` by `run.sh`) listing every `*.zip` on the SMB
+     share with an Installed/Install status per game; the user clicks "Install" to
+     fetch+extract a specific game into `${GAMES_HOME}` on demand.
 
 - **Manifest-driven games + Start/Stop/Uninstall**: games are no longer discovered from raw
   `*.zip` files on the share. `setup_server.py` lists `*.json` manifests instead (one per
@@ -53,6 +53,22 @@
   happened to exactly match each zip's existing top-level folder name, so no change was
   needed to the install/extraction logic itself, only to where zips are looked up from.
 
+- ~~Handle multiple games running at once~~ Done: each running game now gets its own
+  ephemeral X session (`Xvnc`+`fluxbox`+`websockify`, its own display `:90`-`:99` and noVNC
+  port `8090`-`8099`) spun up by `start_game()` and torn down by `stop_game()` (or lazily on
+  the next page load, if the game exited/crashed on its own) — instead of every game sharing
+  one screen and fighting over focus/audio. Capped at `MAX_CONCURRENT_GAMES = 10`; starting
+  an 11th game while all 10 slots are in use is refused with an error shown on its row rather
+  than silently doing nothing. There is no more a single shared "default" desktop or global
+  noVNC link — `server.sh` no longer starts Xvnc/fluxbox/websockify at container startup at
+  all, only `setup_server.py` itself; each game's own "Open Screen" link appears on its row
+  only while it's running, built with a little client-side JS (the noVNC port differs from
+  the setup port and can't be known server-side without knowing which hostname the browser
+  used to reach the container). `run.sh` publishes the whole `8090-8099` range up front,
+  since Docker can't add port mappings to an already-running container. Verified end-to-end
+  with two different games running concurrently (separate processes, separate displays,
+  separate noVNC ports, independent stop/teardown) and the 10-slot cap logic.
+
 - Get game sound actually audible during play. `--device /dev/snd` is passed through and
   `alsa-utils` is installed, so DOSBox can write to an ALSA device inside the container, but
   VNC/noVNC only ever streams video, not audio — nothing currently carries that sound out to