git 的仓库信任模型：一个一个堵 config 项不收敛

[Spc-jgs]

从 #17 拆出来。那条 issue 记的四个具体口子都堵上了，但堵的方式本身不收敛。

已经堵上的四个

config 项	什么时候跑	怎么堵的
core.fsmonitor	每条 git status	-c core.fsmonitor=
diff.external	看差异	-c diff.external= + --no-ext-diff
diff.<名字>.textconv	看差异	--no-textconv（名字任意，-c 点不着）
filter.<名字>.smudge/clean/process	检出、暂存	先 git config --local 查出名单，再逐个 -c 关
remote.<名字>.url = ext::…	fetch / push	-c protocol.ext.allow=never

每一条都有一条验过红的测试。

为什么这还不够

这五条是一个一个查出来的。查的过程是：想到一个 → 写个仓库试试 →
真的执行了 → 堵上。

下一个能让 git 执行命令的 config 项被发现之前，我们不知道它存在。

而且其中一条（ext::）暴露了一个更糟的形状：git 自己的默认防线是仓库
能掀掉的 —— 默认 protocol.ext.allow 不允许，但仓库在自己的
.git/config 里写一句 always 就放开了。同一个形状可能还有别的。

这类口子的共同点：

• .git/config 是仓库带来的文件，不是用户写的
• 触发它们的大多是普通操作（status / 检出 / fetch），不需要用户点什么特别的
• 出事的时候没有任何提示

真正的解法：这个目录信不信得过

VS Code 的受限模式、git 自己的 safe.directory 都是这个思路：
第一次打开一个陌生仓库时问一句，不信任就整块 Git 功能不启用
（就像现在「不是 git 仓库」时那样隐身）。

判据从「这个 config 项危不危险」变成「这个目录我信不信」——
后者是收敛的，前者不是。

要想清楚的几件事（一件都没定）

1. 问的时机。 打开文件夹、拖进窗口、命令行 lite-ide <目录>、
   会话恢复四条路都会设项目根。会话恢复那条尤其麻烦 ——
   启动时弹一个模态问「信不信得过」，体验很差。
2. 信任记在哪、按什么粒度。 路径？还是路径 + 某种指纹？
   记在 localStorage 还是 Rust 侧？（rules/frontend.md 那条
   「启动路径上的代码一律不许抛」适用。）
3. 不信任时到什么程度。 只关 Git 功能？还是连文件都只读？
   这个应用「不是 git 仓库」时 Git 整块隐身，那套现成的形状可以复用。
4. 和 issue git 操作的提示不成体系：慢操作一声不吭，失败大多是 git 的英文原话 #15 是同一块界面。 那条刚把 git 的失败翻译成人话，
   信任提示如果另起一套长相，就又是「同一件事两种说法」。

别做的

不要因为「已经堵了五条」就把这条降级。堵住的是已知的五条，
而这条 issue 要解决的正是「未知的第六条」。