fix(一致性): 两处相互冲突的建议，其一会让读者悄悄失去本书推荐的默认后端

- 18.1 完整演示了如何开启 `userns-remap`，全程没有任何代价提示。但官方文档
  明写「The containerd image store is not available when using user namespace
  remapping」，而本书基线是 Docker Engine v29.x——该版本新装默认就是
  containerd image store，12.4 节还把它标为「强烈推荐（现代默认）」。照 18.1
  做完，读者会在毫不知情的情况下退回旧存储后端，失去 OCI image index、多架构
  镜像与构建溯源。补上这条互斥关系并交叉引用 12.4。
- 5 章说「生产环境建议指定确切版本号（如 nginx:1.28.0）而非仅大版本号」，
  7 章说「使用主或次版本号而非完整版本号（patch）」并把 patch 版本列入
  「避免」。两条都以全书建议的口吻写成，方向正好相反。它们其实面向不同环节：
  Dockerfile 的**基础镜像**用主/次版本号，才能在重新构建时自动带上安全补丁；
  **部署**一个服务镜像则应钉死确切版本，让部署可复现、升级是显式动作。
  两处各补一句限定范围并互相指引，而不是删掉其中一条。

18_security/18.1_kernel_ns.md

@@ -45,6 +45,12 @@ Docker 守护进程在启动容器时，会在后台为容器创建一套独立
 ```
 使用 `default` 值时，Docker 会自动在宿主机上创建一个名为 `dockremap` 的用户和用户组。
 
+> **注意其代价**：官方文档明确 **containerd image store 在启用 `userns-remap` 时不可用**。
+> 而本书基线是 Docker Engine v29.x，该版本新装默认就是 containerd image store，
+> [12.4 节](../12_implementation/12.4_ufs.md) 也把它标为「强烈推荐（现代默认）」。
+> 也就是说，打开 userns-remap 会让你退回旧的镜像存储后端，失去 OCI image index、
+> 多架构镜像与构建溯源等能力。两者只能二选一，请按威胁模型权衡。
+
 2. **验证子 UID 和子 GID 分配**
 
 Docker 会通过 `/etc/subuid` 和 `/etc/subgid` 文件为 `dockremap` 分配一个高位的 UID 范围：