docs: the C environment is declared, not implied --- the macro rules and the wave's records

.agents/docs/2026-09-17-openkal-0.13-ecosystem-record.md

@@ -50,7 +50,15 @@ mcpp-index 分两次合并，原因是 openkal-emscripten 与 std-freestanding-a
 
 ## 4. 验证
 
-**CI。** 每个 PR 合并前 CI 全绿。合并后 mcpp main 上 ci-macos 的 xcode-27 任务变红，原因是 runner 镜像换成 20260912，其 Command Line Tools SDK 的 `.tbd` 含 `arm64e.x1`，而 lld 22.1.8 无法解析（上游 llvm-project#222721）。该任务改用 mcpp 自己选择的 SDK（mcpp#665）后转绿。
+**CI。** 每个 PR 合并前 CI 全绿。合并后 mcpp main 上 ci-macos 的 xcode-27 任务变红，报 `.tbd` 含 `arm64e.x1` 而 lld 22.1.8 无法解析（上游 llvm-project#222721）。
+
+此处当日写下的归因于 2026-09-18 查证后推翻，有两层。
+
+其一，当时 GitHub 在**同时**灰度两个 runner 镜像，并非一夜之间换掉：变红的运行（35213851816，11:05）跑在 `20260912`（Xcode 27 Release Candidate），随后"转绿"的运行（35219991759，12:14）跑在 `20260907`（Xcode 27 beta 6）。同一次推送的 `ci-macos` 与 `ci-macos-e2e` 甚至分别落到两个镜像上，一红一绿。
+
+其二，更要紧：mcpp#665 在机制上就不可能修好它。xlings 的 llvm 包把 `--sysroot`（指向 Command Line Tools）写进 `clang++.cfg`，而命令行的 `-isysroot` 只改头文件搜索、不改链接器的 syslibroot——`--sysroot` 才改。#665 加的正是 `-isysroot`，因此在 xim-pkgindex#858 之前，每一次链接都走 CLT，与 `-isysroot` 说什么无关。那次绿只是因为 CLT 的 SDK 在 `20260907` 镜像上是好的。
+
+#665 仍是正确的改动（用 `xcrun` 报告的 SDK 取代硬编码路径，且确实修好了头文件搜索），但它解决的不是这个问题。详见 mcpp#669。
 
 **沙箱。** `xlings subos use v013 --sandbox`，CN 镜像，mcpp 2026.9.17.3，全部从已发布的索引解析：
 
@@ -84,6 +92,6 @@ ok: the search list of a compat.zlib unit names no host directory
 | 平台库自行创建的线程回调进 C 库代码时没有 C 库状态（R2） | openkal-musl | 仅文档约束 |
 | 事件循环依赖 `epoll`（cmp-module 等） | 按设计 | 测为失败，不推动 `openkal.event` |
 | xz 去掉 `_WIN32` 后在 musl-Windows 上解码失败 | compat.xz | 不适配，测为失败 |
-| xlings LLVM 包的默认 sysroot 在 macOS 27 上无法被 lld 22.1.8 链接 | xlings LLVM 包 | 等待打包带 llvm-project#222721 的 LLVM |
+| xlings LLVM 包的默认 sysroot 在 macOS 27 上无法被 lld 22.1.8 链接 | xlings LLVM 包与 lld | 两层，2026-09-18 查清。其一：该包把 `--sysroot` 写入 `clang++.cfg`，候选列表中 Command Line Tools 的 SDK 排在 Xcode 之前，而 `-isysroot` 只改头文件搜索、链接器的 syslibroot 认 `--sysroot`，故 mcpp#665 在命令行上给出的正确 SDK 盖不过它；已改为先问 `xcrun --show-sdk-path`（xim-pkgindex#858，已合并，日志确认 cfg 现在写的是 Xcode 的 SDK）。其二：同日 runner 镜像由 Xcode 27 beta 6 换为 Release Candidate，其自带 SDK 的 `.tbd` 同样含 `arm64e.x1`，于是两个 SDK 都不可解析——换 sysroot 已无解，仍需带 llvm-project#222721 的 LLVM。9-17 的原判断成立，只是原因比当时所写更宽 |
 | 网络错误值在三个实现间不一致 | openkal | §5.2 的准入标准下暂不增加（缺少测量） |
 | clang 自带头文件（`mm_malloc.h`、`intrin.h`）在 windows-gnu 三元组下假定 MinGW C 库 | openkal-musl 与编译器之间 | 待跟进：影响任何 include SSE/intrin 头文件的包，不是某一个包的问题 |