Add market watch and match hub workflows

docs/runtime-operations.md

@@ -60,6 +60,18 @@
 - media service 暂时抖动时，不会把前台提交动作直接拖成超时
 - 真正的会话校验、归档、回放可用性判断都在 worker 中执行
 
+### 1.4 media-worker 会话刷新
+
+`media-worker` 现在每轮都会从磁盘重新读取 `/data/media/sessions/*/session.json`。
+
+这样做是为了避免独立 worker 只在启动时加载一次会话，导致：
+
+- 新创建的录制会话虽然已经写盘，但 worker 看不到
+- `archiveStatus = queued` 的会话长期卡住
+- `media_finalize` 任务反复重试直到耗尽次数
+
+如果线上出现“归档一直 queued，但 media-worker 没报错”的情况，优先确认当前镜像是否已经包含这项修复。
+
 ## 2. 前端任务观测与降级
 
 ### 2.1 任务中心
@@ -169,6 +181,34 @@ docker compose logs --tail=80 app-worker
 curl http://127.0.0.1:8081/media/health
 ```
 
+如问题涉及训练计划超时或录制归档卡住，优先使用全链路重建，而不是只重启单个容器：
+
+```bash
+docker compose up -d --build migrate app app-worker media media-worker
+```
+
+重启后建议额外确认：
+
+- `docker compose logs --tail=120 app-worker` 中不再出现旧的 `Request timed out after 45000ms`
+- `docker compose logs --tail=120 media-worker` 中 worker 已正常启动
+- 容器内 `dist/worker.js` 已包含新的训练计划超时/自动重试逻辑
+
+## 6.1 损坏 media 会话处理
+
+如果 `media-data` 中出现 `0` 字节或无法解析的 `session.json`，不要继续保留在 `sessions/*` 主目录。
+
+建议处理方式：
+
+1. 将损坏会话目录移动到隔离目录，例如 `sessions_broken/<session_id>`
+2. 保留原始 `segments/*` 作为排障材料
+3. 不直接猜测补写 `session.json`
+
+原因：
+
+- 空 `session.json` 往往意味着写盘被中断
+- 这类会话即使继续重试，也无法可靠恢复业务语义
+- 将其移出主扫描路径可以避免后续 worker 误处理
+
 ## 7. 线上 Smoke Check
 
 全量重启后建议至少执行：