docs: update PROGRESS.md - 队列表schema迁移修复时区残留 + -f mp4修复

PROGRESS.md

@@ -1,6 +1,6 @@
 # 项目进度追踪
 
-> 最后更新: 2026-08-20 18:25
+> 最后更新: 2026-08-20 18:50
 
 ## 服务运行状态
 
@@ -161,6 +161,21 @@
 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 标志，防止线程假死误报
 
+## 时区修复收尾 + 队列表 Schema 迁移 (2026-08-20 18:50, commit 9aba71c/1b82db1)
+
+**时区修复的残留漏洞**（795e8ac 的补充）：该提交只改了 `CREATE TABLE` 的 DEFAULT，但 **DEFAULT 约束固化在已存在表的 schema 中，`IF NOT EXISTS` 不会更新旧表**——enqueue INSERT 未显式传时间戳，新行 created_at 仍走旧 DEFAULT `localtime`（UTC 机器上=UTC）。实证：行 19 (task 42) 18:14 入队 created_at=10:14:22 (UTC)，同刻 UPDATE 语句已是北京时间 18:18。
+
+**三处修复**（commit 9aba71c）：
+1. enqueue INSERT 显式写 `created_at/updated_at = datetime('now','+8 hours')`，不再依赖 schema DEFAULT
+2. `_init_db` 检测旧 schema 含 `localtime` 时事务内重建表迁移（新表+复制数据+drop+rename，幂等可重复执行）
+3. 存量数据修正：行 16/19 created_at +8h
+
+**验证**：本地迁移单测 3 例通过（迁移+数据保留/INSERT 北京时间/幂等）；线上部署后行 20 (task 44) created_at=18:43:35 为北京时间（UTC 机器当时 10:43）；task 44 全链路 SUCCESS（event_id=25，帧时间戳 22:31:15→22:56:15 与视频起点一致）；MariaDB monitor_events/event_details 时间戳全链路北京时间正确。
+
+**附带修复**（commit 1b82db1）：NAS 压缩命令补 `-f mp4` 显式指定 muxer（.tmp 扩展名导致 ffmpeg41 无法推断输出格式，task 43 首轮压缩失败回退 360MB 原始上传）。实测 task 43 压缩 360MB→18.9MB (19.1x) 534s 后原子 rename 成功，直传入队。
+
+**运维教训**：Edge 服务重启必须 `--bind 0.0.0.0:5000`（误用 127.0.0.1 导致 NAS 无法访问，Poller 持续 RemoteDisconnected；本地 curl 掩盖问题）。task 43 因暂时性网络抖动三连超时标记 FAILED，已重置 PENDING 待压缩缓存复用重试。
+
 ## 压缩缓存原子性修复 (2026-08-20 18:25, commit 1994de2)
 
 **根因**（task 300 损坏视频之谜的答案）：服务被 kill 时 dispatcher 死亡但其 ffmpeg 子进程成为**孤儿**（父进程转 init）继续写压缩产物。旧代码直接写最终路径，半成品文件 `size>0` 且 mtime 较新 → 缓存复用判断误判为有效 → 重试任务上传损坏视频。多次重启叠加多个孤儿 ffmpeg 争抢 NAS ARM CPU（本轮实测 3 个并行）。