Harden self-update recovery (T-617)

docs/api.md

@@ -370,7 +370,7 @@ SoftBoxUpdater.exe --pid <主程序PID> --staging <暂存目录> --target <目
 
 这是受约束的本地激活助手，**不是**自更新下载或签名校验入口。`target` 必须是绝对 `<root>/app`，`staging` 必须是绝对 `<root>/staging/<request-id>`；`request-id` 不作为 CLI 参数，助手只从已准备 staging 的末段取得并重新校验安全字符。它拒绝相对路径、交叉 root、符号链接、非目录、已有同 ID backup 和任意可执行路径/参数。
 
-助手先等待正 PID 的旧主进程自然退出（OpenProcess/等待失败、取消或超时均不把它当成已退出），再恢复遗留 transaction 并执行 `prepared → target_backed_up → staging_activated → launched → committed`。它只允许 `app → backups/<request-id>`、`staging/<request-id> → app` 两次受限 rename，并以原子 JSON transaction 和目录同步建立崩溃恢复栅栏；不会写 `data/` 或 `licenses/`，也不会强杀进程。
+助手先等待正 PID 的旧主进程自然退出（OpenProcess/等待失败、取消或超时均不把它当成已退出），再恢复遗留 transaction 并执行 `prepared → target_backed_up → staging_activated → launched → committed`。它只允许 `app → backups/<request-id>`、`staging/<request-id> → app` 两次受限 rename，并以原子 JSON transaction 和目录同步建立崩溃恢复栅栏；`prepared` journal 不能单独决定“尚未移动”：Recover 必须检查真实的 managed target/backup。仅 target 存在且 backup 不存在才可删除 prepared journal；target 缺失且 backup 存在必须先 restore，其他组合保留 journal/材料并返回恢复失败。因而首次 rename 已完成但目录 sync 失败时，调用会先尝试受限恢复，后续 Recover 也不会丢弃旧 app 的唯一恢复证据。它不会写 `data/` 或 `licenses/`，也不会强杀进程。
 
 新版只以 `<root>/app/SoftBox.exe --softbox-update-health <request-id>`、固定工作目录启动。主程序在 Gio Layout 前从自身 EXE 推导 root，且仅当本地 transaction 处于已激活/已启动阶段并匹配 request ID 时，才在 `<root>/self-update-health.json` 原子写入仅含 `schema_version` 和 `request_id` 的确认。助手只接受完全匹配的确认后才清理 backup/transaction；启动或健康失败会尽力恢复旧 `app`，若 Windows 文件锁禁止恢复则保留 journal/backup 供下次受控助手在旧 PID 退出后恢复。退出码:0 成功；非 0 表示未提交或恢复材料仍需处理。