[Bug]: Git 仓库目录所有者与当前运行用户不一致时，审核等功能失败

[guantw]

问题描述

当工作区 Git 仓库根目录的文件系统所有者（owner）与运行 BitFun 的当前操作系统用户不一致时，Git 会触发仓库信任校验（safe.directory），并拒绝在该仓库中执行操作。

典型报错：

fatal: detected dubious ownership in repository at <repo-path>

目前 BitFun 没有对该场景做统一的预检、错误分类或恢复提示，因此“审核/Review”、获取审核 diff、远程仓库探测，以及部分 Git 工作流可能直接失败。

复现条件

1. 准备一个目录 owner 与当前运行 BitFun 的用户不同的 Git 仓库（例如共享目录、挂载目录、容器映射目录或以其他系统用户创建的目录）。
2. 在 BitFun 中将该目录作为工作区。
3. 执行审核/Review、查看 diff 或其他需要 Git 的操作。
4. 操作失败，并在日志或错误链中出现 detected dubious ownership / safe.directory 相关信息。

代码检查证据

这是对当前仓库代码的静态检查结果：

• src/crates/services/services-integrations/src/git/utils.rs:253 等 Git 外部命令封装路径没有注入 scoped safe.directory，命令失败会直接转成 CommandFailed。
• src/crates/services/services-integrations/src/review_platform.rs:790 的工作区探测和 Git 操作使用同类外部 Git 调用。
• src/crates/assembly/core/src/agentic/tools/implementations/get_file_diff_tool.rs:1022 在安全审核路径中把 Git diff 失败包装成 “Git diff is unavailable within the safety boundary”，没有针对所有权不一致做处理。
• src/crates/services/services-integrations/src/remote_ssh/remote_git.rs:23 的远程 Git 命令构造同样没有 safe.directory 策略；远端 SSH 用户与仓库 owner 不一致时也可能触发相同问题。
• CLI 中还有若干直接调用 Git 的路径，可能绕过统一封装。

在当前代码中未检索到 safe.directory、dubious ownership 等专门处理逻辑，现有 Git 测试也未覆盖仓库 owner 与当前用户不一致的场景。当前结论来自静态代码检查，尚未在本机通过跨用户目录复现。

期望行为

• 在 Git 服务层增加统一的仓库信任预检和可识别的错误类型，覆盖审核、diff、远程探测、CLI、远端工作区和其他内部 Git 调用。
• 对用户明确选择并确认的工作区，可在单次/单进程 Git 调用中使用规范化后的仓库根目录作为 scoped safe.directory，不要写入全局 Git 配置，也不要默认使用 safe.directory=*。
• 远程工作区应在远端主机上、以实际 SSH 用户身份执行相同的信任判断。
• 向用户显示明确的处理建议，并补充 Unix owner mismatch、Windows ACL/挂载目录、容器/WSL/NFS/SMB、远程 SSH 等回归测试。

[bobleer]

这个边界抓得很准，尤其是不要写全局配置、不要用 safe.directory=*。

不过目前既然还只有静态检查，我倾向先不把“用户选中过工作区”直接等同于“信任这个 owner”：打开目录和允许 Git 信任该仓库不是同一个授权。方便的话先补一个本机或 SSH 的真实复现，把失败命令、Git 版本、git rev-parse --show-toplevel 结果，以及目录 owner / 当前 uid 脱敏后贴一下。

实现上可以先识别 dubious ownership 为单独错误，弹一次明确确认；确认后只对规范化后的仓库根目录使用命令级 -c safe.directory=...。本地和远端要分别跑，因为远端的判断必须发生在实际 SSH 用户下。