Merge native Windows CI fixes into coverage follow-up

# Conflicts:
#	.agents/notes/implemented/process/2026-08-08-native-windows-pull-request-ci.i18n.yaml
#	.agents/notes/implemented/process/2026-08-08-native-windows-pull-request-ci.md
#	.agents/notes/implemented/process/2026-08-08-native-windows-pull-request-ci.zh.md

.agents/notes/implemented/process/2026-08-08-native-windows-pull-request-ci.zh.md

@@ -16,6 +16,8 @@ Status: implemented
 
 工作区构建、生产网站和逐文件 100% 覆盖率检查失败时，聚合作业会继续阻断；更广泛的静态检查、文档、包和构建产物可移植性清单则作为观测项报告。覆盖率检查的工作线程预算为 4 个；同一台运行器在这些门禁之间共享安装结果与构建输出，串行门禁与 publint 工作线程上限使标准镜像的资源使用保持在可预测范围内。重复执行的 lint 与快照强制检查仍由 Linux 负责。
 
+首次原生运行暴露出两项被兼容性通道掩盖的故障。文档投影测试此前只按 `/` 拆分来派生图片 basename；现在改为使用 Node 根据平台计算的 basename。Chokidar 消费方收到的 `%TEMP%` 以 `C:\\Users\\RUNNER~1` 这个 8.3 别名表示，而 libuv 返回的是长目录名，导致其 Windows 事件路径断言失败。共享的设置 watcher 与凭据 watcher，以及 Cordis 的模块 HMR（热模块替换）与精确配置 HMR，现在都会在打开 watcher 前规范化现有的原生监听基准路径或层级最深的现有祖先路径，并保留尚不存在的后缀；文件访问和诊断仍使用配置路径。
+
 受支持的工作流不含 Wine 专属基础设施：不存在 apt 缓存生产者、兼容性脚本、对仓库快照执行的 hoisted 安装、Windows Node 下载或本地 `check:windows-wine` 命令。[已归档的 Wine 实验](../../archived/process/2026-07-27-wine-windows-gates-experiment.md)仍作为其实测延迟与保真度取舍的历史证据，而非当前执行路径。
 
 ## 曾考虑的替代方案
@@ -32,4 +34,6 @@ Status: implemented
 
 在聚合作业通过之前，拉取请求会获得来自真实 NT 内核、NTFS、PowerShell、Windows 进程和原生插件的信号。该作业比 Wine 兼容性通道更慢，也可能因 Windows 容量而排队，但其绿灯结果描述的是受支持的宿主，而非近似环境。
 
+原生通道也是一份可移植性清单：其分支头精确验收要求每个阻断门禁都通过，且最终汇总中不包含任何非阻断失败。这一区分发现了路径契约问题；若只看包装层的成功结论，这些问题本会被掩盖。
+
 移除 Wine 缓存生产者和本地脚本后，独立的安装拓扑及其反复出现的兼容性故障也随之消失。原生 Windows 覆盖率现在通过同一项必需作业运行，并强制执行仓库的逐文件覆盖率阈值；该覆盖率门禁不会为受支持的 LSP 行为设置仅针对 Windows 的源码排除项。原生 Windows 快照仍是明确列出的缺口，不会仅由作业名称暗示已经纳入；必须先为其建立专门且经过测试的契约，才能成为该必需通道的一部分。