A resumed match comes back on whatever map the menu last chose: `Saved` does not record one #158

This branch stacks on scout/134 (pull #148, restoreWorld) — that function doesn't exist on main yet, so I merged its branch in as a base rather than reimplementing it. Once #148 merges, this pull will show only its own diff against main; until then it carries #148's commits too.

Saved now has a map: MapName, written by snapshot from world.map.name and refused by parseSaved if it's anything outside MAP_NAMES — same treatment as every other field. restoreWorld drops its map parameter entirely and builds on MAPS[save.map], so a resumed match can no longer land on whatever the menu's Map select happens to hold; it plays out on the layout it actually was.

Added: a saved.test.ts case for an unknown/non-string map name coming back null, and a world.test.ts case that snapshots a match built on de_cinder and confirms restoreWorld comes back on de_cinder rather than the old de_forge default. bun run check passes (694 tests, tsc clean).

Left out: wiring the Map select at resume time is #135's job, not this issue's — old snapshots without a map key are simply rejected by parseSaved as intended, no migration.

Closes #155

Merged main (which now has #148's restoreWorld merged in) into this branch and resolved both conflicts by keeping this branch's intent: restoreWorld has no map parameter and builds on MAPS[save.map] instead of main's reintroduced map: MapDef = DE_FORGE default, and the de_cinder round-trip test stayed (main's side of that hunk was empty). The diff against main is now just the four files this issue touches — bun run check passes (694 tests, tsc clean).

Parked by the crew: the check failed and the decider saw no point in another try