style(docs): standardize heading formats and numbering

- Enforce Level 1-3 structural numbering based on SUMMARY.md hierarchy
- Remove structural numbering from Level 4+ headings
- Eliminate single child headings by converting to bold text
- Auto-inject summary text for headings with multiple children missing intro text
- Exclude Appendix chapters from structural numbering
- Avoid modifying code block contents
- Add script to detect non-standard English usage in headers

04_image/4.7_internal.md

@@ -2,7 +2,7 @@
 
 Docker 镜像是怎么实现增量的修改和维护的？为什么容器启动如此之快？这一切都归功于 Docker 的镜像分层存储设计。
 
-### 镜像与分层存储
+### 4.7.1 镜像与分层存储
 
 在之前的章节中，我们一直强调镜像包含操作系统完整的 `root` 文件系统，其体积往往是庞大的。因此在 Docker 设计时，就充分利用 **Union FS** 的技术，将其设计为分层存储的架构。
 
@@ -17,7 +17,7 @@ Docker 镜像并不是一个单纯的文件，而是由一组文件系统叠加
 *   **复用**：如果多个镜像都基于同一个基础镜像 (例如都基于 `ubuntu:24.04`)，那么宿主机只需要下载一份 `ubuntu:24.04`，所有镜像都可以共享它。
 *   **轻量**：镜像仅仅记录了与基础镜像的差异，因此体积非常小。
 
-### 容器层与读写
+### 4.7.2 容器层与读写
 
 我们要理解的一个关键概念是：**镜像的每一层都是只读的 (Read-only)**。
 
@@ -48,7 +48,7 @@ flowchart TD
 1.  **容器删除后数据会丢失**：因为所有的数据修改都保存在最上层的容器层中，容器销毁时，这个层也就随之销毁了。(除非使用了数据卷，详见[数据管理](../08_data_network/README.md))。
 2.  **镜像不可变**：无论我们在容器里删除了多少文件，基础镜像的体积并不会减小，因为它们依然存在于底层的只读层中。
 
-### 内容寻址与镜像 ID
+### 4.7.3 内容寻址与镜像 ID
 
 Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的内容计算出来的哈希值 (SHA256)。这意味着：
 
@@ -56,7 +56,7 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
 *   **安全性**：确保了镜像内容的完整性，下载过程中如果数据损坏，ID 校验就会失败。
 *   **去重**：如果两个不同的镜像 (甚至是不同来源的镜像) 包含相同的层 (ID 相同)，Docker 引擎在本地只会存储一份，绝不重复下载。
 
-### 联合文件系统
+### 4.7.4 联合文件系统
 
 Docker 使用联合文件系统 (Union FS) 来实现这种分层挂载。常见的驱动包括 `overlay2` (目前推荐)、`aufs` (早期使用)、`btrfs`、`zfs` 等。