Fix docs lint: zh heading parity and an interrogative table header

- docs/zh/21-the-target-triple.md was missing the zh mirror of the new
  "a declared environment can move the compiled triple" note; heading
  count parity with the English document now holds (25/25).
- docs/zh/24-openkal-cross.md's macro-family table header "由谁定义"
  reads as a question (contains 谁); renamed to the noun phrase "定义者".
- Three cross-file anchors in the zh docs pointed at the ENGLISH heading
  slug of their target section instead of the zh one
  (#adaptation-to-the-resolved-target-side, #closure-visibility) — fixed
  to the zh anchors check_docs_structure.sh actually validates against.

Caught by CI on #668 ("build + unit tests" job's doc-lint step); verified
locally afterwards with check_docs_style.sh, check_docs_structure.sh,
check_version_pins.sh, check_target_tiers.py and check_modules_wiring.sh.

Author: speak-agent

docs/zh/06-features-and-capabilities.md

@@ -450,7 +450,7 @@ some.windows-headers = { version = "1.0", visibility = "private" }
 #### 让闭包也能看见它,而不只是私有(mcpp 2026.9.18+)
 
 `visibility = "private"` 回答的是「这个依赖会不会泄漏到消费方的 `-I` 列表」,不回答
-「这个依赖到底在不在图里」——后者是[22 —— 目标侧](22-target-side.md#closure-visibility)
+「这个依赖到底在不在图里」——后者是[22 —— 目标侧](22-target-side.md#闭包可见性)
 要为**整个构建**回答的问题。由 SDK 包自己陈述报告或拒绝开关需要的事实:
 
 ```toml

docs/zh/21-the-target-triple.md

@@ -416,6 +416,17 @@ CRT;图供给时是 `musl`。一个目标字符串,两个不同的 C 库 ——
 全部差别就在于用的是哪个 C 库。任何宿主都没有为它准备的载荷;它的系统只能来自依赖
 图,这正是 `toolchain list` 报的 `via dependency graph`。
 
+### 声明的环境能移动编译三元组,移动不了链接三元组(mcpp 2026.9.18+)
+
+`c-abi` 包的 `[c-abi]` 块([22 —— C 环境](22-target-side.md#c-abi-包陈述它呈现的-c-环境mcpp-2026918))
+可以改变一次**编译**收到的 `--target=`——图里的 C 库声明 `presents = "posix"` 时,
+`x86_64-windows-gnu` 按 `x86_64-pc-cygwin` 编译——而不改变本章讲的那个三元组。
+解析出的三元组(`mcpp toolchain list` 打印的拼法、输出目录名、`Target` 报告的
+标题行、**链接**行)照旧是图与工具链解析出的那个;被替换的只是编译命令自己的
+`--target=` 记号,因为环境身份宏与数据模型正是从这里来的。如果在
+`compile_commands.json` 里 grep `--target=` 找到一个本章列表里没有的拼法,看到的
+正是这件事——原因与触发条件见 docs/22。
+
 ## 构建机是第三条轴
 
 上面两条轴 —— 用哪个编译器、C 库从哪来 —— 是工程做的选择。第三条不是:它是构建

docs/zh/24-openkal-cross.md

@@ -33,7 +33,7 @@ C++ 运行时 —— 成为一组由依赖图解析、并由当前运行的编
 回答了其中两个——这正是每一次 openkal-Windows 失败的根因,其诊断都指向一份缺失的平台
 头文件:代码本想问「这是不是 openkal」,却用了一个实际意味着「Windows CRT 是否在场」的宏。
 
-| 宏族 | 陈述 | 由谁定义 | 例子 |
+| 宏族 | 陈述 | 定义者 | 例子 |
 |---|---|---|---|
 | 内核 ABI | `kal_*` 可调用,且在每个平台上行为一致 | 提供 `mcpp:kernel-abi=openkal` 的层 | `__openkal__` |
 | C 环境 | 源码看到的 C 环境形状 | 提供 `mcpp:c-abi=<impl>` 的层,通过 [`[c-abi]`](22-target-side.md#c-abi-包陈述它呈现的-c-环境mcpp-2026918) | `__unix__`、`_WIN32`、`__MINGW32__` |
@@ -49,7 +49,7 @@ C++ 运行时 —— 成为一组由依赖图解析、并由当前运行的编
 *禁止:* 用它选择头文件、推断 `_WIN32` 是否为真、绕开缺失的 SDK,或者区分
 `linux`/`windows`/`macos`。那些是 C 环境层或平台层的问题——在清单里写
 `cfg(c-abi = "…")` 或 `cfg(kernel-abi = "…")`(谓词语法见
-[22 —— 适配已解析出的目标侧](22-target-side.md#adaptation-to-the-resolved-target-side))。
+[22 —— 对已解析目标侧的适配](22-target-side.md#对已解析目标侧的适配))。
 
 **平台单元。** 自己需要平台原生环境的包——openkal-windows,或者
 [06 的私有依赖模式](06-features-and-capabilities.md#平台-sdk-依赖保持私有)下的平台 shim——