fix(mining): 修复 Windows 挖掘锁状态误报

锁诊断优先使用当前后端实际持锁对象确认自身归属，避免 Windows 排他锁阻止二次读取文件时误报未知持有者。真实外部占用仍按陈旧判定处理，并拒绝终止当前持锁后端。

验证：83 项相关 pytest 通过，Ruff 和 git diff --check 通过。原生 Windows 安装包仍待实机复验。

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

docs/mining.md

@@ -110,6 +110,8 @@ run 级的“有效折”统计只描述因子赛道：它按每折被选中的
 
 **挖掘锁冲突的降级与强制释放**：数据目录的 `.mining_process.lock`（flock）保证同一时刻只有一个应用进程负责挖掘；持锁者会把 `{pid, started_at, role}` 写进锁文件（flock 仍是唯一事实，内容只是诊断线索，旧格式 `"0"` 视为持有者未知）。撞锁不再导致后端启动失败——面板以降级模式运行：挖掘启动入口（手动/自动/周度调度）返回 409，守护复验等其他功能不受影响；挖掘页顶部显示持有者横幅（pid、角色、挖掘存储静默时长）。当且仅当满足陈旧判定（持有者信息可读、进程存活且 pid 未被复用、无进行中的挖掘运行、挖掘存储 10 分钟内无写入——全部 fail-closed，任一不满足即拒绝并给出原因）时，可一键「强制停止并接管」：终止持有者进程并由当前后端获取锁，挖掘入口立即恢复。不做启动时自动清理——终止进程是破坏性操作，必须人工确认。
 
+锁状态接口优先使用当前后端实际持有的锁句柄确认归属。Windows 的字节范围排他锁会阻止另一个句柄读取锁文件，即使两个句柄属于同一进程；读取诊断信息失败时，不能把已持锁的当前后端误报成未知残留进程。真正的外部占用仍按上述陈旧判定处理，启动标志本身不能代替实际持锁状态。
+
 每个运行目录包含 manifest、compact summary、最近 256 条事件和四个 Parquet artifact。大面板、完整矩阵对象和逐折宽结果不会通过 worker IPC 返回。
 
 ## 自动运行