Chat autosave re-opens a new runtime session generation on every tick after a failed status/delete (67 generations, ~700 requests in 6 min)

With server-backed persistence, when the runtime store answers a session status PATCH or a session DELETE with a server error, the chat sync gives up on the current generation and the next autosave tick opens the same chat as a fresh …:generation:N session. syncOne bounds one save (8 attempts × 8 plan steps, with backoff), but every autosave starts a new save, so the schedule restarts from zero.

Measured on a v1.0.3 deployment (6-scene course open for 6 minutes): session-…:generation:1 … :generation:67 for one scene, ~700 requests to /api/persistence/runtime/…, a growing table of empty runtime_sessions rows, and a browser tab close to freezing. The store's error body is never surfaced (the client wrapper swallows it), so the operator cannot even see what the server answered.

Proposal (PR follows): a per-stage brake above the sync — after a failed save, skip further saves for that stage until a growing cooldown elapses (5 s → 5 min cap), clear on success, and log the store's status/code/message once per trip.