fix(门禁脚本): 缺 .map 时说明"本树从未构建"，并写进工作树文档

票面：task-20 交付后的回报——全新工作树没有 .map，依赖它的门禁必然红，而现场只看到一句
"找不到 .map 事实源"，容易误判成代码问题。（Lead 定的两头修法都做，本笔独立于 UI 改动。）

- scripts/check_mem_numbers.py：FAIL 后补三行原因与动作——.map 是**每棵工作树各自的**构建产物、
  不入版本库，新开的工作树（task-worktree new）从未构建过时必然走到这里，先 @build 一次即可，
  再按需要 ram_baseline.py --update 回填台账。保持 FAIL 语义不变，只把提示词写对。
- scripts/ram_baseline.py：两处（--update / --write 路径）同样的补充说明。
- docs/环境与部署/并行任务工作树方案.md：生命周期表加一行「新空间首次：@build 一次生成 .map」，
  表下补一段说明点名 mem-numbers / mem-budget / L0c 三个消费者。
- .dsh/skills/task-worktree/SKILL.md：陷阱区加同一条，并与既有的「done 的门禁跑在 @build 之前
  → .map 是旧的」明确区分——一条是"有但旧"，一条是"根本没有"，处置动作不同。

只改提示文案与文档，不改判定逻辑与阈值；两个脚本 py_compile 通过并实测打印。
跳过的门禁（三条同族）：mem-numbers / mem-budget / size-gate（L0c）——本笔恰恰是在解释其中两条
为什么会红，数值本身仍等 Lead 回填。

docs/环境与部署/并行任务工作树方案.md

@@ -270,10 +270,17 @@ D:/Code/DTU Code/
 | ------- | ------------------------------------ | ------------------------------ |
 | 任务期     | `scripts/ci_local.py`（L0 + L0.5，可并行） | 每个任务各自跑                        |
 | 任务期     | `@build`（0 错 0 警，**持 `build` 锁串行**）  | 每个任务各自跑                        |
+| **新空间首次** | `@build` 一次，生成 `.map`             | 见下表下注释：不先构建，体积类门禁必然红        |
 | 任务期（可选） | `@test` / 板级套件（持 `bench` 锁）          | 需真机验证的任务                       |
 | 回收期     | 重生成产物 → `ci_local.py` → `@build`     | `done` 内强制（`--skip-gates` 可跳过） |
 | 人工      | push 许可                              | 回收后                            |
 
+> ⚠ **新开工作树后先 `@build` 一次再谈门禁**（实测 2026-10-25）：`.map` 是每棵树各自的构建产物、
+> 不入版本库，所以依赖它的事实源的门禁——`mem-numbers`、`mem-budget`、以及 `ci_local.py` 的
+> `L0c`——在从未构建过的新空间里**必然红**。这不是代码缺陷，脚本此时也会把这句原因打出来
+> （`check_mem_numbers.py` / `ram_baseline.py` 的提示文案）。顺带一条同源提醒：`done` 的门禁
+> 排在 `@build` 之前（见下文陷阱条目），同一族误报在回收期也会重现一次。
+
 **`done` 的完成判据**：主干上 `git merge --no-ff` 成功 + `ci_local.py` 全绿 + `@build` 0 错 0 警
 
 - 残留审计无死规则/重复条目 + 工作树已移除。