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

snapshot (src/client/saved.ts) was fixed in #133 when de_forge was the only layout. #153 landed a second one, chosen before the match, and main.ts now builds its world with createWorld(rules, name, team, 5, undefined, settings.difficulty, mapFor(settings.map)) (main.ts:612). Nothing in a snapshot says which of the two the match was played on.

restoreWorld(save, difficulty, map) (#134, pull #148) takes the map as its own parameter and defaults it to DE_FORGE, so the resume wiring in #135 has no source of truth to pass it: whatever the Map select happens to hold at resume time is the map you come back on. Change the select between a crash and a resume — or just have last played on de_cinder with the menu remembering de_forge — and round 9 of your match restarts on a different layout, with the score, the money and the gear of the match you were actually playing. Spawns, sites and bot plans all move under you.

Done looks like:

• [ ] Saved carries map: MapName, written by snapshot from world.map and validated in parseSaved against MAP_NAMES — anything else is null, like every other field there.
• [ ] restoreWorld takes the map from the save rather than from a default, so a resumed match cannot land on a layout it was never played on. Its map parameter goes, or becomes an override with a reason.
• [ ] A test that fails without it: snapshot a match built on de_cinder, restore it, and the restored world's map is de_cinder; and a parseSaved of a snapshot with an unknown map name is null.

Files: src/client/saved.ts, src/client/saved.test.ts, src/client/world.ts, src/client/world.test.ts.

Risks: an old snapshot in someone's localStorage has no map key and must not crash — it is simply not a snapshot parseSaved accepts any more, which is the existing rule and needs no migration. Keep the diff to the field and its validation; #135 owns the menu.

Found reviewing pull #148.

Parked by the crew: the check failed and the decider saw no point in another try (pull #158 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Split in two, because the pull that tried it could not say which half broke. #158 closed on a check that reported nothing but test exited with code 1, and it had changed saved.ts and world.ts in one diff on a branch stacked on another pull's branch (scout/134, six commits). Nothing in the finding was wrong — it is a real hole, and it is still worth building — but that shape makes a red check unreadable.

• #160 — Saved gains map, validated like every other field. saved.ts and saved.test.ts only: written by snapshot from the world's own map, refused by parseSaved when it is missing, not a string, or not in MAP_NAMES, with the "old snapshots are refused, no migration" decision stated in one line. restoreWorld keeps its parameter for now. Ready.
• #161 — restoreWorld reads the map from the save. world.ts and world.test.ts only: the map parameter goes, MAPS[save.map] replaces it, callers updated, and a test that a match snapshotted on de_cinder comes back on de_cinder. Waits on #160.

Both carry the same instruction, which is the one concrete thing that differed in #158: branch from main, not from another pull's branch, and run bun run check on a clean clone before pushing. main is green at 7b34305 — 692 pass, 0 fail — so a red check is the branch's own, and bun test --rerun-each 2 is worth a minute when the summary says nothing.

This issue is linked behind both and wants a person to close it once they land. #135 (the resume wiring) now waits on #161 rather than on this.

Done, and closing: this was split into #160 (Saved gains map) and #161 (restoreWorld reads it), and both have merged — #163 at 013620e and #170 at 246ba57. A snapshot now records the map it was played on and a restore comes back on it, which is everything this issue asked for. #135 is what is left of the resume chain, and it no longer waits on anything open here.