Preserve state on hot reload

[T4rk1n]

Add dev_tools_hot_reload_preserve_state: keep UI state across hot reloads

When enabled, the renderer records UI-driven prop edits, set_props
updates (clientside, serverside and websocket) and memory-type dcc.Store
writes as [newVal, originalVal] pairs. Just before a hot reload - soft
RELOAD dispatch or full page reload - they are snapshotted (in memory +
sessionStorage), then re-applied to the incoming layout unless a prop's
initial value changed in the reloaded code, in which case the new code
wins. Unmatched edits stay pending so components inserted by callbacks
(e.g. pages content) are restored too. The snapshot is only written when
a hot reload fires and consumed on use, so a manual browser refresh
still resets the app.

Off by default; enable with dev_tools_hot_reload_preserve_state=True or
DASH_HOT_RELOAD_PRESERVE_STATE=true.

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.3% Duplication on New Code

See analysis details on SonarQube Cloud

[BSd3v]

I dont know if this would be worth it or if people would be interested, but could expand this to keep the current state of executed callbacks for seeing in the callback graphs.

[KoolADE85]

This is a cool feature, I will find this useful in my own work!
Can we distinguish between "reloading the same app" and "starting a completely different app"?
If you are working on "App A" locally (http://localhost:8050) and you switch to "App B" which happens to share a common callback:

@callback(Input("clear", "n_clicks"))
def clear(n_clicks):
    if not n_clicks:
        raise PreventUpdate

    # does something benign in App A
    # does something destructive in App B

then clicking the button in App A, will cause a problem in App B.
And it wouldn't be obvious that the source of the "bug" came from a button click in App A.

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
4.2% Duplication on New Code

See analysis details on SonarQube Cloud

[T4rk1n]

@KoolADE85 Good catch, that's a real hazard. I've scoped the preserved state per app: when `preserve_state` is on, the server persists this page's `end_id` to disk keyed by the app path (stable across the reload, unique per app), and the renderer keys its sessionStorage snapshot by it. A different app served on the same URL gets a different `end_id`, so it reads a different key and can never restore another app's state — your App A button click can't reach App B, `n_clicks` included. It reuses the same signed `end_id` token we already mint per page load for background-callback handles.