[ci] 没有任何 job 构建大链接包 — argv 上限类缺陷对全部 18 个 CI job 不可见 #346

背景

PR #345 在 18/18 CI job 全绿之后，被本地跑真实 mcpp-index workspace 抓到一个回归：

ninja: fatal: posix_spawn: Argument list too long

opencv-module / opencv-module-dnn / opencv-module-unifont 三个成员全挂。
根因是 POSIX 上 ninja 用 sh -c "<整条命令>"，整条命令是一个 argv 项，
撞 MAX_ARG_STRLEN(128 KiB)。已在 #345 里通过「全平台一律走 response file」修掉。

缺口本身

没有任何一个 CI job 构建 opencv/ffmpeg 这一量级的包。 所有 job 构建的都是
mcpp 自身（几十个 TU）或 e2e 里的合成小工程（个位数 TU）。所以：

• 链接行长度、rspfile 路径、大 obj 集合的 ninja 图规模 —— 全部零覆盖
• 任何让对象路径变长、或让链接输入变多的改动，CI 都不会有反应
• 这类缺陷的失败模态还特别差：ninja 的 Argument list too long 不报是哪条边、
  哪个文件、什么原因

修复前的余量是可测的：opencv-module 的内联链接行本来就已经 56 840 字节，
占 128 KiB 上限的 43% —— 也就是说这条线一直悬着，只是没人看。

判据(建议)

不是「把 opencv 加进 CI」(太慢)。需要的是对链接规模本身的断言，而不是对某个大包的构建：

1. 一个合成 e2e：生成 N 个源文件(N 足够大，比如 3000)，断言构建成功
   —— 这直接覆盖 argv/rspfile 路径，且不依赖任何外部包，跑得也快(可用 -O0 空函数)。
2. 或者更便宜的：在 ninja backend 的单测里断言"链接命令中不含内联 $in"
   (fix(cache): a package's object layout must not depend on the consumer (#344) #345 已加这条)，再补一条 e2e 证明 rspfile 真的被 ninja 执行、且产物正确。

方案 1 是真正覆盖"规模"这个轴的那个；方案 2 只覆盖"形状"。建议至少做 1。

关联

• fix(cache): a package's object layout must not depend on the consumer (#344) #345(发现处 + argv 修复)
• [bug] Windows driver-style 链接不走 rspfile:大型源码包(ffmpeg/opencv,数千对象)链接命令行溢出 CreateProcess 32KiB 上限 #247(Windows CreateProcess 32 KiB，同一族的上一次)
• feat: mcpp test capability batch — isolation, parallel, filter, list, timeout, JSON (0.0.104) #274(ninja 目标 argv 50781 字符超 cmd.exe 8191，同一族的上上次)

同一族已经第三次了 —— 三次都是靠真实大包在生态侧崩出来，而不是靠 CI。