feat(mining): 挖掘锁撞锁降级启动 + 持有者诊断 + 一键强制释放

复现的原始问题: 旧实例挂死在 shutdown (热重载撞上挖掘运行) 或 worker
成为孤儿后, `.mining_process.lock` 被无限期占用, 后续所有后端实例
在 lifespan 抢锁时直接启动失败, 用户只能对着笼统报错手动找进程。

- 锁文件记录持有者 {pid, started_at, role, host} (flock 仍是唯一
  事实, 内容只是诊断线索; 旧格式 "0" 兼容, 视为持有者未知);
  新增非阻塞探测, 无需抢锁即可判断是否被持有。
- 撞锁降级启动: lifespan 抢锁失败不再上抛, 面板照常可用; 挖掘
  启动入口 (手动/自动/周度调度) 返回 409 并指引到挖掘页; 桌面版
  预检从「秒退失败页」改为留日志继续启动; 守护复验不受影响。
- 挖掘页锁占用横幅: 显示持有者 pid/角色/挖掘存储静默时长; 满足
  陈旧判定时可一键「强制停止并接管」(SIGTERM→SIGKILL→当前后端
  获取锁, 挖掘入口立即恢复)。
- 陈旧判定全部 fail-closed: 持有者信息可读、进程存活且 pid 未被
  复用 (POSIX 比对进程实际启动时间)、无进行中的挖掘运行、挖掘
  存储 10 分钟内无写入 — 任一不满足即拒绝并给出原因。不做启动
  时自动清理, 终止进程必须人工确认。

测试: 新增 test_mining_lock_admin (含真实外部持锁进程的强停回路与
五类拒绝路径), 重写 lifespan 降级契约与桌面预检继续启动契约;
后端全量 3239 通过, 前端 308 通过, ruff 零新增; 沙盒 E2E 完整
复刻「持锁→降级→强停→接管→恢复」事故场景通过。

Signed-off-by: shy3130 <shy3130@qq.com>

docs/mining.md

@@ -108,6 +108,8 @@ run 级的“有效折”统计只描述因子赛道：它按每折被选中的
 
 当前 run store 和重任务 limiter 使用进程内锁。生产环境必须只启动一个应用进程负责挖掘；多 worker Uvicorn 部署不能保证跨进程单飞、事件追加和容量限制。要支持多应用进程，必须先增加操作系统级文件锁或外部任务协调器。
 
+**挖掘锁冲突的降级与强制释放**：数据目录的 `.mining_process.lock`（flock）保证同一时刻只有一个应用进程负责挖掘；持锁者会把 `{pid, started_at, role}` 写进锁文件（flock 仍是唯一事实，内容只是诊断线索，旧格式 `"0"` 视为持有者未知）。撞锁不再导致后端启动失败——面板以降级模式运行：挖掘启动入口（手动/自动/周度调度）返回 409，守护复验等其他功能不受影响；挖掘页顶部显示持有者横幅（pid、角色、挖掘存储静默时长）。当且仅当满足陈旧判定（持有者信息可读、进程存活且 pid 未被复用、无进行中的挖掘运行、挖掘存储 10 分钟内无写入——全部 fail-closed，任一不满足即拒绝并给出原因）时，可一键「强制停止并接管」：终止持有者进程并由当前后端获取锁，挖掘入口立即恢复。不做启动时自动清理——终止进程是破坏性操作，必须人工确认。
+
 每个运行目录包含 manifest、compact summary、最近 256 条事件和四个 Parquet artifact。大面板、完整矩阵对象和逐折宽结果不会通过 worker IPC 返回。
 
 ## 自动运行