docs: update PROGRESS.md - 压缩缓存原子性修复

PROGRESS.md

@@ -1,6 +1,6 @@
 # 项目进度追踪
 
-> 最后更新: 2026-08-20 18:05
+> 最后更新: 2026-08-20 18:25
 
 ## 服务运行状态
 
@@ -161,6 +161,14 @@
 19. **chunk_size 变更防护** - Edge 端 upload_chunk 检测 total_chunks 变更（由 chunk_size 变化导致），自动清理旧分块防止混合不同大小分块导致 assemble 后文件损坏。NAS 端 _query_uploaded_chunks 比对 expected_total != edge_total 时跳过断点续传
 20. **看门狗机制** - app.py 启动 daemon 看门狗线程，每 60s 检查 scheduler/dispatcher/poller 线程 is_alive()，崩溃自动 check_and_restart()。/api/status 改用 thread.is_alive() 替代 _running 标志，防止线程假死误报
 
+## 压缩缓存原子性修复 (2026-08-20 18:25, commit 1994de2)
+
+**根因**（task 300 损坏视频之谜的答案）：服务被 kill 时 dispatcher 死亡但其 ffmpeg 子进程成为**孤儿**（父进程转 init）继续写压缩产物。旧代码直接写最终路径，半成品文件 `size>0` 且 mtime 较新 → 缓存复用判断误判为有效 → 重试任务上传损坏视频。多次重启叠加多个孤儿 ffmpeg 争抢 NAS ARM CPU（本轮实测 3 个并行）。
+
+**修复**：压缩输出写 `{out}.{pid}.tmp`（带 PID 防多进程冲突），成功后 `os.replace` 原子 rename——缓存目录只可能出现完整产物；`_cleanup_compress_cache` 顺带清理超 1h 的 .tmp 残留。
+
+**运维**：已杀孤儿 ffmpeg×2（task 43/44）并清理缓存目录、重置任务状态；每次重启 NAS 服务后应检查 `ps aux | grep ffmpeg41` 是否有孤儿残留。
+
 ## 视频时间语义修正 (2026-08-20 18:05, commit 80b2fcc)
 
 时区统一的延伸排查发现三处**时间语义** bug（时区对了但语义错）：