mcpp test 运行测试时持有构建目录锁：测试内部调用同一工作区的 mcpp build 会一直等锁；测试环境里内层 mcpp 的配置哈希也不同 #915

现象

mcpp test 在运行测试期间一直持有构建目录的锁。如果某个测试本身要在同一个工作区里调用 mcpp build / mcpp run（例如一个"开发宿主"的端到端测试：它监视示例工程的源码、调用 mcpp 增量构建、运行新构建），这个内层的 mcpp 会一直等锁：

Waiting for the build directory, held by pid 139740 (mcpp test -p ..., 58s)

直到测试被 --timeout 杀掉。同一个测试程序脱离 mcpp test 直接运行（MCPP_BIN_<NAME> 手动设好）是通过的。

另外，在 mcpp test 给测试进程的环境里，PATH 最前面是 ~/.mcpp/registry/subos/default/bin；内层 mcpp build 在这个环境下解析出的配置哈希与平常不同（target/<arch>/<另一个哈希>），等于从头再构建一遍整个工作区——这和锁是两件事，但会让这类测试即使拿到锁也很慢。

复现

一个工作区成员的测试里：

// 测试运行中，在本工作区的另一个成员目录里
os::process::run({.program = "mcpp", .args = {"build"}, .cwd = repo / "examples/01-hello-im"});

mcpp test -p <该成员> → 内层 build 等锁直到超时。

可能的方向（由维护者决定）

1. 运行阶段释放构建锁：测试构建完成后，运行测试时不再需要独占构建目录（或降为共享锁），让测试里的 mcpp 能用同一个构建目录；
2. 或者在报错/等待提示里说明这是"测试自身调用了 mcpp"，并给出推荐做法（例如 --no-run 后直接运行测试程序）；
3. 测试进程的环境里，内层 mcpp 应解析出与外层相同的工具链与配置（PATH 前缀不应改变配置哈希），避免重复全量构建。

目前我们的做法：mcpp test -p <成员> --no-run 构建，然后在 CI 里直接运行该测试程序。