fix(content): correct Docker Engine 29.0.0 date and align login-action version

Docker Engine 29.0.0 was released 2025-11-10 per docs.docker.com release
notes, not 2025-11-11 (off by one day). Also bring docker/login-action
reference in 18.6 up to v4 to match the 21.2 example (v4 has been current
since 2026-03-04).

04_image/4.7_internal.md

@@ -60,7 +60,7 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
 
 Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载。传统的实现方式常见于 `overlay2`、`aufs`、`btrfs`、`zfs` 等存储驱动；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
 
-> **版本背景**：Docker Engine 29.0.0 发布于 2025 年 11 月 11 日，是一个重要版本分界点。Docker Engine 29.0 及之后的全新安装默认使用 containerd image store；从更早版本升级的 daemon 会继续使用 legacy graph driver，直到显式启用 containerd image store。Docker Desktop 4.34 及之后也默认启用 containerd image store，实际环境仍应以当前配置为准。
+> **版本背景**：Docker Engine 29.0.0 发布于 2025 年 11 月 10 日，是一个重要版本分界点。Docker Engine 29.0 及之后的全新安装默认使用 containerd image store；从更早版本升级的 daemon 会继续使用 legacy graph driver，直到显式启用 containerd image store。Docker Desktop 4.34 及之后也默认启用 containerd image store，实际环境仍应以当前配置为准。
 
 虽然底层实现细节不同，但它们都遵循上述的 **分层 + CoW** 模型；因此，无论你看到的是 `overlay2` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的方式都是一样重要的。
 

18_security/18.6_image_security.md

@@ -466,7 +466,7 @@ jobs:
 
     - name: Login to Registry and Push
       if: github.event_name == 'push'
-      uses: docker/login-action@v3
+      uses: docker/login-action@v4
       with:
         registry: ${{ env.REGISTRY }}
         username: ${{ github.actor }}