[fx-kurumi]

Closes #751

改了什么

• internal/runtime/git_isolation.go：把 gitIndexLockHeldUnder 里最内层「扫描单个进程 fd 目录、判断是否有描述符指向锁文件」的循环拆为私有函数 fdDirHoldsFile(dir, want string, lock os.FileInfo) (bool, error)。
  • 按路径（target == want）或 inode（os.SameFile）命中返回 true；返回的 error 只表示 fd 目录本身读取失败。
  • 跳过 socket / pipe / 匿名 inode（非 / 开头）的规则、注释和判定顺序逐字不变。
• gitIndexLockHeldUnder 只保留锁文件校验、/proc 遍历和「读不到 fd 目录 → 是否记为不确定」的判定，嵌套从三层循环降为两层。
• 新增 internal/runtime/git_index_lock_fd_test.go：TestFdDirHoldsFile 覆盖空目录、pipe/socket/anon_inode、指向其他文件、悬空链接、同路径命中、硬链接同 inode 命中、fd 目录不存在返回 os.ErrNotExist。

为什么

原函数把锁文件校验、进程遍历、fd 链接匹配和「不确定」判定写在同一个函数里，最内层逻辑只能借助真实 /proc 或伪造整棵进程树间接测试。拆出后单进程扫描可以直接单测，主函数读起来就是「遍历进程 → 读不到如何处理 → 命中即返回」。不改导出接口，不改行为。

怎么验证的

• gofmt -l internal/runtime 无输出；go vet ./internal/runtime/ 通过。
• go test ./internal/runtime/ -run 'FdDirHoldsFile|GitIndexLock|IndexLock'：新增测试及现有 TestGitIndexLock*、TestRestoreProjectAgentGitIndex*、TestProjectAgentGitIndexLockWaitStopsOnCancel 全部通过（bind mount 用例本机按原逻辑 SKIP）。
• go test ./internal/runtime/ 全量：7 个失败（2 个需要 Chromium、5 个 Docker 相关用例在全量跑时失败），在未改动的 origin/main 上全量跑失败列表完全相同；这 5 个 Docker 用例在本分支单独跑全部通过，与本次改动无关。

🤖 Generated with Claude Code

[Yanami-2K]

对照 #751 核对了完整 diff：fdDirHoldsFile 逐字搬移了单进程 fd 扫描（跳过非 / 开头的链接、先比路径再比 inode），只把 ReadDir 错误返回给调用方，gitIndexLockHeldUnder 的 uncertain 判定和命中返回值均未变。TestFdDirHoldsFile 用伪造 fd 目录断言了 pipe/socket、其他文件、悬空链接、同路径、硬链接同 inode 和目录不存在返回 NotExist，CI 全部通过。

[Yanami-2K]

更正：上一条 APPROVE 评审末尾的 sha 标记写错了，评审结论不变，实际审查的 head 为 29093c7。

[fx-kurumi]

复审结论：✅ 通过（head 29093c72）

• internal/runtime/git_isolation.go 从 gitIndexLockHeldUnder 抽出 fdDirHoldsFile：ReadDir 失败时原样返回 error，调用方据此保留 uncertain 判定（os.ErrNotExist 且属主可能匹配时仍标记不确定）；符号链接只接受绝对路径目标，先比路径、再 os.Stat + os.SameFile 比 inode —— 两个判定条件和顺序都没变，return true, true, nil 的语义一致。
• 本机（Go 1.26.11）：go vet ./internal/runtime/ 通过；go test ./internal/runtime/ -run 'TestGitIndexLock' -count=1 ok。
• CI 16 项全部通过。

没有发现问题。