feat(ui): add canvas snapshot save/restore functionality

[GGSSKK]

Summary

Adds a canvas snapshot save/restore button to the toolbar (camera icon). Users can save the current canvas state at any time and restore it later — useful when the canvas resets unexpectedly due to freezes or reloads.

Reuses the existing client_state API with a canvas_snapshot: key prefix, keeping changes minimal.

snapshot.mp4

Related Issues / Discussions

Related to #6554 (canvas state not persisting). This provides a manual workaround by letting users explicitly save/restore canvas state.

Changes

Snapshot save/restore (original)

• New CanvasToolbarSnapshotMenuButton component with save input, restore list, and per-snapshot delete
• useCanvasSnapshots hook backed by client_state persistence API
• canvasSnapshotRestored reducer in canvasSlice

Review feedback (368fe74)

• bbox.modelBase preservation: Snapshot restore now keeps the current model's modelBase instead of blindly overwriting it from the snapshot. Prevents bbox grid/dimension desync when the user switches models after saving. Follows the same pattern as resetState.
• Undo history exclusion: canvasSnapshotRestored is filtered out of redux-undo history so Undo cannot accidentally discard a just-restored snapshot.
• RTKQ migration: Replaced manual fetch + getAuthHeaders() with a new clientState.ts RTKQ endpoint file. Snapshots now go through dynamicBaseQuery, gaining automatic auth token injection, 401 session-expiry handling, and sliding-window token refresh.
• Missing image detection on restore: Collects all image_name references (including regional guidance reference images) and checks their existence via getImageDTOSafe before restoring. Shows a warning toast with the count of missing images.
• Incompatible snapshot detection: Catches ZodError from zCanvasState.parse() and shows a specific "incompatible version" error instead of a generic failure toast.
• Staging guard: Disables restore and delete menu items while the canvas is staging to prevent entity ID conflicts with in-progress generations.
• Snapshot ordering: Changed ORDER BY rowid DESC → ORDER BY updated_at DESC in get_keys_by_prefix so re-saved snapshots move to the top of the list.
• Offline safety: Pre-flight backend reachability check (getAppVersion) before image validation to avoid false "missing images" warnings when offline.
• Reconnect refresh: Added FetchOnReconnect tag to the snapshot list query so it auto-refreshes after websocket reconnect.

QA Instructions

1. Add layers, adjust bbox, add regional guidance with reference images on the canvas
2. Click the camera icon in the toolbar → save a snapshot (leave name blank for auto date/time)
3. Reset canvas via New Session
4. Click the camera icon → select the snapshot to restore
5. Verify layers, masks, bbox dimensions, and selection state are restored
6. Test deleting a snapshot via the trash icon
7. Switch to a different model (e.g. SD1.5 → SDXL) → restore a snapshot → verify bbox dimensions are preserved but model stays current
8. Press Ctrl+Z after restoring → verify the restore is NOT undone
9. Save a snapshot with the same name as an existing one → verify it moves to the top of the list
10. Start a generation → while staging, open the snapshot menu → verify restore items are disabled
11. (Optional) Disconnect network → attempt restore → verify no false "missing images" warning

Merge Plan

Simple merge. No DB schema changes — uses existing client_state table. New RTKQ endpoint file (clientState.ts) added.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Changes to a redux slice have a corresponding migration — N/A, no state shape change (new reducer only)
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[DustyShoe]

A very welcome feature. Also useful if you want temporarily switch to something else.
Should have mentioned that it breaks if user did clear intermediates in settings.

[DustyShoe]

Here's some finding done with LLM regarding this PR as a heads up for reviewer.

Review Pass 1: Broader Review

• High: Restoring a canvas snapshot copies the entire saved bbox, including modelBase. That can desynchronize the canvas from the currently selected model if the user changed models after saving the snapshot. As a result, size, grid, and optimal-dimension logic may run against the wrong model base.
• Medium: Snapshot restore currently goes through the normal undoable canvas history. That means Undo right after restore can jump back to the pre-restore state, and history also keeps another full canvas state in memory. This feels inconsistent with other full-canvas replacement flows that clear history.
• Low: Snapshot ordering is currently based on rowid DESC, not on last update time. If a user overwrites an existing snapshot with the same name, it will not move to the top of the list even though it was just re-saved.
• Optimization: The snapshot client code uses manual fetch calls and manual auth header handling even though the frontend already has a shared API transport layer. Moving this into the existing API layer would make it easier to maintain and less error-prone.
• Optimization: The snapshot list is fetched eagerly on mount. That adds a request every time the canvas loads, even if the user never opens the snapshot menu. Lazy-loading on first open would be cleaner.

Open questions:

• Should restoring a snapshot also restore the selected model, or is it only supposed to restore canvas layers within the currently active model context?
• Should snapshot restore be treated as a new baseline state, or is it intentional that Undo can immediately return to the pre-restore canvas?

Review Pass 2: Issues Actually Introduced By This PR

• High: The new user-management API allows removing or deactivating the last active administrator through PATCH /auth/users/{user_id}. There is a guard against deleting the last admin, but the same invariant is not enforced for update operations, so the system can still end up with zero active admins.
• High: Canvas snapshot restore can reintroduce a stale bbox.modelBase from the saved snapshot. If the current model changed after the snapshot was created, restoring it can leave the canvas state out of sync with the active model.
• Medium: The edit-user modal keeps local form state initialized from the first selected user and does not resync when editUser changes. That means opening user A, closing the modal, and then opening user B can show or submit stale values from user A.
• Low: PATCH /auth/users/{user_id} returns 400 for a nonexistent user, even though the route contract says it should return 404.
• Low: Snapshot ordering is based on insertion order (rowid DESC) instead of updated_at, so re-saving an existing snapshot name does not move it to the top.

Open questions:

• Is it expected that an admin can demote or deactivate the final active admin account, or should the “cannot remove the last admin” invariant apply to updates as well as deletes?
• For the edit-user modal, is the intended UX that each open always reflects the currently selected user from server state, even when the modal component instance is reused?

As an addition:

• High: Canvas snapshots are not durable if the user clears intermediates. Snapshot save serializes the current canvas state, but canvas image objects only store image references (image_name, width, height), not the image payload itself. Clearing intermediates deletes the backing image files. After that, restoring a snapshot brings back canvas objects that still point to the old image_names, and image loading fails because those images no longer exist. In practice, that means a saved snapshot can become unrecoverable after a routine “Clear intermediates” action.

Open question:

• Are snapshots intended to survive “Clear intermediates”? If yes, the current approach likely needs to either persist referenced images as non-intermediates, embed durable image data, or warn/refuse when a snapshot depends on intermediate-only images.

[GGSSKK]

Thanks for the thorough review! Addressed each point in 368fe74.

Issues fixed in this PR

Finding	Resolution
High: bbox.modelBase desync on restore	Snapshot restore now preserves the current modelBase and calls syncScaledSize() — same pattern as resetState. Bbox dimensions are restored exactly as saved.
High: Snapshots break after Clear Intermediates	On restore, all image_name references (including regional guidance ref images) are validated via getImageDTOSafe. Missing images trigger a warning toast with the count. A pre-flight health check avoids false warnings when the backend is unreachable.
Medium: Undo can revert a snapshot restore	canvasSnapshotRestored is now excluded from redux-undo's filter. After restoring, Undo steps back through the undo history that existed before the restore — it does not return to the canvas state immediately prior to the restore. This is intentional: restore is treated as a non-reversible baseline replacement.
Low: Snapshot ordering by rowid	Changed to ORDER BY updated_at DESC. The tg_client_state_updated_at trigger already updates this column on upsert.
Optimization: Manual fetch bypasses shared API layer	Migrated all calls to a new RTKQ endpoint file (clientState.ts). Snapshots now go through dynamicBaseQuery with automatic auth, 401 session-expiry handling, and sliding-window token refresh. Also added FetchOnReconnect tag so the list refreshes on reconnect.
Optimization: Eager fetch on mount	Acknowledged. The snapshot list is still fetched eagerly on mount. Migrating to RTKQ provides caching and deduplication, which mitigates the impact. Lazy-loading via RTKQ's skip option on first menu open could be a follow-up optimization.

Additional fixes

• Staging guard: Restore and delete are disabled while the canvas is staging, preventing entity ID conflicts with in-progress generations.
• Incompatible snapshots: ZodError from schema validation is caught and shows "This snapshot was created with a different version" instead of a generic failure.

Issues not in this PR's scope

The three auth/user-management findings (PATCH last-admin guard, edit-user stale state, 400 vs 404) are real bugs, but they were introduced by #8937 — this PR's only auth change is the remember_me field from #9017. These should be tracked and fixed in a separate PR.

Open questions answered

• Should restore also restore the selected model? No — snapshots restore canvas layout only. Model selection is a user intent that should not be overridden by a snapshot. modelBase is preserved from the current state.
• Should Undo revert a snapshot restore? No — restore is excluded from undo history via redux-undo's filter. After restoring, Undo walks back through the history that existed before the restore, not to the canvas state immediately prior (which is intentionally not saved as an undo point). This treats restore as a deliberate, non-reversible baseline replacement.
• Should snapshots survive Clear Intermediates? Rather than promoting images (which would pollute the gallery), we validate on restore and warn. The main use case (crash recovery) doesn't involve clearing intermediates between save and restore.

Notes from main merge

• collectImageNames consolidation: Snapshot restore previously had its own local collectImageNames. After merging with main, which introduced a shared, more comprehensive version in canvasProjectFile.ts, the snapshot code was updated to reuse the shared function for consistency (DRY). Snapshots don't include global ref images, so an empty array is passed for that parameter.
• canvasProjectRecalled pattern divergence: During the merge we noticed that the canvasProjectRecalled reducer (feat(ui): add canvas project save/load (.invk format) #8917) directly assigns bbox without preserving the current modelBase or calling syncScaledSize(), and is included in undo history — unlike the pattern established in canvasSnapshotRestored. This may warrant aligning in a follow-up PR to avoid potential bbox/model desync on project load.

[GGSSKK]

Merged with latest main and resolved a conflict in canvasSlice.ts (both canvasSnapshotRestored and canvasProjectRecalled exports were added at the same location).

Also consolidated collectImageNames — snapshot code previously had its own local version, now reuses the shared one from canvasProjectFile.ts introduced by #8917.

One thing to note: the canvasProjectRecalled reducer from #8917 does not preserve modelBase or call syncScaledSize(), and is not excluded from undo history — unlike the pattern in canvasSnapshotRestored. This could cause the same bbox/model desync on project load. Added this to the review summary above; may warrant a follow-up.

[Pfannkuchensack]

Works good.
Added:

• Escape %, _, \ in client_state prefix query to prevent accidental wildcard matching
• Confirm before overwriting an existing snapshot instead of silently replacing it
• Use - instead of / and : in the default snapshot name to avoid key separator clashes

[Pfannkuchensack]

I fixed the found in canvasProjectRecalled.