Function handle_save_session_snapshot 

pub(crate) async fn handle_save_session_snapshot(
    state: &AppState,
    _call: &WebCallType,
) -> WebReturnType

Attempt to replay the durable “last session” snapshot (if any) into a fresh workspace: CreateWorkspace → per-tab CreateTab + per-block CreateBlock (reusing each block’s saved meta, so a restored agent pane relaunches the same way opening a fresh one does) → LayoutSetTree with the saved split tree (block ids remapped from placeholders to the newly created ones).

Returns Ok(None) when there’s nothing to restore (no snapshot, or every tab in it failed to recreate) — the caller falls back to the hardcoded default seed exactly as it did before this feature existed. Returns Err only for a failure in the very first step (creating the workspace itself); per-tab/per-block failures during replay are logged and skipped rather than aborting the whole restore, so a partially-stale snapshot (e.g. one tab’s block meta no longer makes sense) still restores everything else instead of failing shut. Snapshot the current session WITHOUT tearing anything down.

This is the OS-shutdown flush point (SPEC_CONTINUOUS_SESSION_PERSISTENCE_2026_09_08.md Phase 0). It exists because the only existing writer of the session snapshot is window_close.rs, gated on the close that empties Client.windowids — so a Windows restart, which terminates the process without ever calling CloseWindow, has always left no snapshot at all and lost the workspace. Verified against a real incident: the killed instance’s DB had session:last_topology absent, windowids still populated, and 22 orphaned blocks.

Deliberately does NOT run delete_workspace. The OS is about to reclaim every process anyway, and that saga’s 5s-per-shell KILL_GRACE_SECS does not fit inside the OS’s shutdown budget (historically ~5s total, and Windows kills apps that overstay it). Save, then let the process die.

Takes no arguments: during shutdown the caller is a native wndproc with no convenient window-id/label mapping in hand, and srv already knows its own current topology. Resolves the workspace the same way the close path does — via the single Client’s first window — so a restore after an OS shutdown reconstructs exactly what a restore after a clean quit would have.

Idempotent and safe to call repeatedly: it overwrites the same Client.meta key, and a single attempt here never retries or blocks on failure, so a shutdown flush can never wedge the shutdown it is trying to protect. That is a statement about this call itself staying fast and single-shot, not about what it reports: unlike the clean-close path, save_last_session_snapshot’s result here IS propagated into the response (success: false on either an unbuildable snapshot or a failed store write), because the caller — the cef-side shutdown hook — relies on that to decide whether to re-arm for a genuine retry on the OS’s own second trigger.