QQ频道运营台 v7.8.5 最终修正版回归报告
========================================

最新现场日志结论
----------------
现场日志已经明确出现：
stage = restore_restart_requested
command = QQ频道本地多QQ运营台.exe --apply-cloud-restore

但之后没有：
- apply_enter
- pending_selected
- apply_package_extracted

因此云快照下载、SHA256、pending ZIP、marker、重启参数都正常。
真实故障是：自定义冻结/打包入口下，第二个 EXE 进程没有可靠进入恢复执行器。

架构修复
--------
一键自动恢复不再依赖“第一次重启应用数据”。

新的主链路：
1. 当前进程下载并校验云快照。
2. 写入 pending ZIP + marker。
3. 停止自动化发布 worker。
4. 停止普通发布 worker。
5. 停止 QQ 群 worker。
6. 暂停新的自动云备份。
7. 等待正在运行的自动云备份线程结束。
8. 销毁 Tk 主界面，释放 GUI/数据库工作线程。
9. 当前进程立即执行 apply_pending_restore()。
10. 创建恢复前本地回滚快照。
11. 解压并替换 local_manager.db 等结构化数据。
12. 校验 accounts/channels/posts 数量。
13. 成功后只做一次普通干净启动。
14. 失败则自动回滚，再普通启动并显示失败结果。

真实 SQLite 集成回归
--------------------
隔离环境创建真实项目数据库：
- 恢复源：accounts=1, channels=25
- 人工破坏后：accounts=0, channels=0
- 执行 pending restore 后：accounts=1, channels=25
- active_db_counts_match=True
- restore result success=True
- pending ZIP/marker 已清理
测试通过。

冻结打包修复继续保留
--------------------
- app._secure_entry 正式冻结入口
- app._frozen_runtime_deps 原生依赖锚点
- select / _socket / _ssl / _sqlite3 等原生依赖验证
- requests / urllib3 / bs4 / soupsieve 收集
- packaged_entry --package-smoke-test
- verify_packaging_entry.py

热更新保持不变
--------------
与上一份 v7.8.5 字节级一致：
- app/updater.py
- make_update_package.py
- 07_PACKAGE_UPDATE.bat

版本仍为 v7.8.5。
