A match survives the tab closing: a snapshot worth resuming, and a world that starts from it #291

Close the tab mid-match here and the match is gone. trevato/cs keeps it: src/client/saved.ts is the value a match is worth keeping — the score, the round, the map, the economy, and nothing a tick is half-way through — and restoreWorld starts a world from it without touching createWorld's signature.

What to take is the idea, not the file. In this repository:

• the snapshot is the shooter's, so it is src/client/ and validated at its boundary the way parseSettings is: a hand-edited or half-written localStorage entry parses to null, never to a partial match;
• it records the map it was played on — a generated map is its seed, and src/client/generate.ts already makes the same place from the same seed, so a resumed match comes back on the map it was played on and not on the default one;
• restoreWorld sits beside createWorld in src/client/world.ts and takes the same level and rules; a round mid-flight is not restored, the round it was in is restarted;
• the menu offers it: "resume" beside "play", and the offer goes when the match ends or is walked out of.

The board already tolerates it — src/db.ts takes a post for a match id that is already there and never lowers its numbers — so a resumed match posts to the row it was posting to.

Done when: a match survives a reload, the resumed world is the one that was saved (a test that plays rounds, snapshots, restores and steps both to the same digest), and a corrupt or stale entry is refused rather than played.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.