Resume match: the menu offers the round you were in, and the row on the board continues #135

Make a refresh, a crash or a closed tab come back at the start of the round you were in.

The last third of #71, and the only part a player sees. It waits on the snapshot and on restoreWorld, and it is wiring: main.ts writes and clears, the menu offers, the matchId continues.

Done looks like:

• [ ] main.ts writes a snapshot at the start of every freeze time — fresh or resumed — and clears it when the match ends or Leave match is used. One key, bounded size, storage failure ignored.
• [ ] The menu offers Resume match — round 9, 5–3 when parseSaved returns a snapshot, and says what starting a new match will discard. The old snapshot is discarded only once the new match actually starts (start() is at main.ts:590 and mints matchId at :596).
• [ ] A resumed match posts under the same matchId, so the row it already has continues instead of duplicating — including a row that went abandoned on db.ts's ten-minute age rule coming back to live. Say in the pull what happens when two tabs resume the same snapshot, and make that answer safe.
• [ ] The resume button and the discard warning are rendered server-side in pages/game.ts with their ids in the contract main.test.ts checks (#99) — main.ts reaches for nothing that is not in that list.
• [ ] The README says what survives a refresh and what does not (nothing mid-round: no position, no health, no bomb), and that it is one browser on one device.
• [ ] A test that fails without it: with a valid snapshot in storage, the menu offers a resume and names the round; with a corrupt one, it does not and the menu is unchanged.

Files: src/client/main.ts, src/pages/game.ts, src/client/main.test.ts, README.md.

Risks: the abandoned-to-live flip is the same seam as #108 (a match's numbers must not go backwards); read it first, and if the safe answer needs #108's guard, say so in the pull rather than shipping a race. Keep the diff off world.ts entirely — the two issues before this one own that file.

Crew: scout.

Now waits on #155 as well as #134. sentinel's catch is exactly the hole in this issue as written: snapshot was fixed when de_forge was the only layout, main.ts:612 now builds a world with mapFor(settings.map), and restoreWorld(save, difficulty, map) (pull #148) takes the map as a parameter — so the wiring this issue describes has no source of truth for which map to resume on, and would silently come back on whatever the Map select happens to hold.

So when this is picked up, the snapshot already carries a map name and this issue's job is simply to pass it: restoreWorld(save, settings.difficulty, mapFor(save.map)), with the menu's resume line saying which map it will come back on — Resume match — de_cinder, round 9, 5–3 — because that is now information the person needs before they press it. Add one line to the acceptance checklist in that shape, and a test that a snapshot naming the map the select does not currently hold still resumes on the snapshot's map.