add: mcpplibs.clangtidy 0.1.0 —— clang-tidy 作为构建规则

[Sunrisepeak]

本索引里的第二个规则包,也是整个生态里 role = "check" 的第一个消费者。

[build-dependencies]
clangtidy = { version = "0.1.0", host-module = true }
llvm      = { version = "...",   tools = ["clang-tidy"] }

// build.mcpp
import std; import mcpp; import clangtidy;
int main() {
    std::vector<std::string> files{ "src/main.cpp" };
    return clangtidy::check(files) ? 0 : 1;
}

它在 2026.8.29.1 之前写不出来

check 的产物是 stamp,而此前命令必须自己创建它。clang-tidy 成功时什么都不写,
于是每个工程都要写同一个包装脚本 —— 而 action 的 command 是 argv、不假设有 shell,
这对 Windows 是对的,也正是那个包装器在那里写不出来的原因。
mcpp#525 起由引擎写 stamp。

⚠️ 旧 mcpp 上不会报错。 少了 stamp,ninja 不会失败 —— 它只是每次构建都重跑那条
边。检查看起来一直在通过,而它从未被满足。下限写在描述符的注释里,因为索引表达不了它。

这个包替消费者解决的两件事

clang-tidy 报了诊断仍然退 0。 实测。而 check 的契约是退出码即判定,所以一个只是
「把 clang-tidy 跑起来」的规则,产生的是一个对它将见到的每一个输入都通过的检查,
而发现会在绿色的构建里滚过去。warnings_are_errors 默认开。

stamp。 图需要一个文件标记这条边已满足,而 clang-tidy 不写。引擎在命令退 0 时
创建它 —— 所以这里没有包装脚本,消费者的工程里也不需要。

核验

• 描述符用已发布的 mcpp 2026.8.29.1 解析:Form A、三平台、versions 有值
• 例子在已发布二进制下:构建通过、stamp 存在、程序运行
• 注入一处真实 bugprone-not-null-terminated-result:构建失败并点名那一行,
  stamp 不产生;不改任何东西再构建一次仍然失败(旧 stamp 不会掩盖它)
• CN 镜像 mcpp-res/clangtidy 已建并回探:ranged GET 吐字节(206),
  与 GitHub 那份逐字节一致。⚠️ gtc 的退出码两个方向都会撒谎,所以判据是回探