存档异步恢复前注册保存，失败后可能覆盖原始聊天存档 #55

用户影响

无效的聊天存档解析失败后，页面已经注册的 beforeunload / visibilitychange 保存回调仍可能把默认内存状态写回 msg-buffer，覆盖原始存档。当前是结构化源码顺序证据，尚未进行坏存档浏览器复现，不声称已有实际数据丢失。

现有顺序

默认分支 299ad570e408180bb4846029355dff6c335b632d，通过官方 query def 检查：

• app.main/main! 先渲染、注册 watcher 及调用 persist-storage! 的离页/隐藏回调，再调用 hydrate-storage-later!。
• hydrate-storage-later! 使用零延时 timeout，读取 msg-buffer 后直接 parse-cirru-edn 并 dispatch hydration；解析/规范化失败会传播。
• persist-storage! 从 *reel 读取当前 Store，格式化后直接 .set-item! 同一个 key，不记录恢复是否成功。

修复方向

保留原异步恢复、解析失败传播和存档格式，但只在成功读取/恢复（或明确没有存档）后注册持久化回调。不要捕获失败后清空、制造默认成功，或删除原保存功能。通过官方 query/tree/edit 的受保护事务修改，保留页面 hud!。

验收应覆盖正常存档恢复/更新后刷新，以及全新来源的合成坏存档启动与刷新后原值保留。不读取真实存档/密钥，不调用模型。PR #54 正式版迁移不等同此项已经解决。