bmi_schedule="on": the split BMI edge loses `include_dirs` on a windows-host cross build

[Sunrisepeak]

[build] bmi_schedule = "on" 在 windows 宿主交叉编译到 x86_64-linux-musl 时,
分离出来的 BMI 边拿不到 include_dirs,构建失败:

failed: gcm.cache/mcpp.libs.json.gcm
D:/a/mcpp/mcpp/src/libs/json.cppm:3:10: fatal error: json.hpp: No such file or directory
    3 | #include <json.hpp>
compilation terminated.

src/libs/json.cppm 在全局模块片段里 #include <json.hpp>,而该头文件由
mcpp.toml 的 [build] include_dirs = ["src/libs/json"] 提供。同一份 manifest、
同一次构建,关掉这个键就正常。

复现

CI job:cross-build-test / windows→linux cross-build (windows host),
run 31868038102。
在 mcpp 自己的 mcpp.toml 里加 [build] bmi_schedule = "on" 即可。

宿主是 windows(mcpp 本身为 x86_64-windows-msvc),目标 x86_64-linux-musl,
工具链 gcc ⇒ 策略是 DetachCodegen。

已知范围

linux 自举 + 全量 e2e	绿(cold 35.40s vs 基线约 80s,83 个单测全过)
macOS / windows 原生 e2e	绿(clang ⇒ two-phase)
windows 宿主交叉到 linux-musl	红

所以这不是「这个特性不能用」,而是某一条宿主 × 策略组合下 BMI 边的命令构造
漏了包含目录。

大概在哪

ninja_backend.cppm 里 detach 的 BMI 边把整条命令写进 $out.cmd:

rspfile_content = $cxx $local_includes $cxxflags $unit_cxxflags... $in ...

而 windows 上普通编译边是把 $local_includes 放进另一个 rspfile($out.rsp)
再用 @ 引用(命令行长度限制)。两条路径对 $local_includes 的处理不一样,
而失败的正是前者。需要确认的是:交叉构建时 $local_includes 是否为空、
还是被 bmi-compile 读回来执行时丢掉了。

现状

已在 mcpp 自己的 mcpp.toml 里回退(那一行改成了说明为什么不开的注释)。
对所有人的默认值 auto 本来就等于关,不受影响。

⚠️ 这条正好印证了 auto 为什么不能凭一台机器的数据翻成 on:linux 全绿、
本地自举全绿、两个平台的原生 e2e 全绿,只有一个宿主 × 目标组合是红的。