fix: replace vulnerable container bases and release v0.1.21

docs/BUILDING.md

@@ -2,50 +2,30 @@
 
 ### Build networking and cache
 
-The Dockerfile retains the pinned Python base, locked Python dependencies,
-`fonts-noto-cjk`, Debian repository signature checks, and offline artifact
-SHA256 verification. Production uses `scripts/build-verify.sh`; CI uses `scripts/ci-compose-verify.py`.
-Both build the same Dockerfile with BuildKit and retain `docker compose build --pull`.
+The runtime uses an official Python 3.14 Alpine 3.24 image pinned by digest,
+locked Python dependencies, and `font-noto-cjk` for Chinese rendering. APK
+repository signatures and offline wheel SHA256 checks remain enabled.
+Production uses `scripts/build-verify.sh`; CI uses `scripts/ci-compose-verify.py`.
+Both build the same Dockerfile with BuildKit and `docker compose build --pull`.
 
-APT mirror hosts are configurable through `DEBIAN_MIRROR` and
-`DEBIAN_SECURITY_MIRROR` (hosts only, without scheme or path). Defaults are
-`deb.debian.org`; HTTPS is used for both Debian and security repositories.
-For mainland-China NAS builds, use the shared profile:
+`ALPINE_MIRROR` accepts a mirror host (without scheme or path), defaulting to
+`dl-cdn.alpinelinux.org`. For mainland-China builds:
 
 ```sh
 . ./deploy/build-cn.env
 ./scripts/build-verify.sh
 ```
 
-CI loads this same profile, using Tsinghua TUNA for both repositories unless
-Gitea repository variables `DEBIAN_MIRROR` / `DEBIAN_SECURITY_MIRROR` override
-it. Production may also set the two hosts directly in `.env` when calling the
-build script without the profile. An alternate mainland mirror is
-`mirrors.ustc.edu.cn`; availability and throughput depend on the Runner network.
-No fallback disables signature verification or removes packages.
+CI uses this profile; the Gitea `ALPINE_MIRROR` repository variable can override
+it. APK upgrades available packages during a fresh dependency-layer build.
+Use `docker compose build --pull --no-cache` to refresh OS packages explicitly.
 
-Layer order stays: pinned base → APT/font dependencies → `requirements.lock`
-→ pip dependencies → application/vendor source → build metadata.
-A source-only change therefore reuses the APT and pip layers, provided the
-same builder, base digest, mirror arguments, and optional offline artifacts
-are used. Changing the lockfile rebuilds pip and later layers, not APT.
-Changing the mirror or APT instructions rebuilds APT and later layers.
-
-Previously an APT layer miss redownloaded indexes/packages, and pip used
-`--no-cache-dir`. Now locked BuildKit mounts retain APT indexes, downloaded
-`.deb` files, and pip downloads/wheels outside the final image. Debian's
-`docker-clean` hook is disabled so it cannot discard cached packages.
-Re-executed APT steps still run `apt-get update` and validate repository
-signatures; cached packages and pip artifacts can avoid repeat large downloads.
-The initial build after this Dockerfile change will miss dependency layers;
-subsequent builds benefit. No measured speedup is claimed before CI completes.
-
-Caches belong to the Docker builder, not the ephemeral CI workspace. Keep the
-NAS Runner's builder storage across jobs; removing the builder, pruning caches,
-or using a fresh Docker daemon loses the benefit. Cache mounts are disposable:
-an empty cache still builds correctly. `--pull` remains enabled; a pinned base
-digest check alone does not invalidate dependency layers. To deliberately
-refresh installed APT versions, use `docker compose build --pull --no-cache`.
+Layer order is pinned base → APK/fonts → requirements → Python dependencies
+→ application source → metadata. BuildKit caches pip downloads separately for
+musl and architecture. Optional `build-cache/wheels/` must contain compatible
+musllinux wheels and their SHA256 manifest; empty-cache builds work normally.
+Do not reuse Debian/manylinux wheels on Alpine. Caches are disposable builder
+resources and are not runtime mounts or dependencies.
 
 ### CI with a host Docker socket
 
@@ -94,8 +74,8 @@ certificate environment settings, and proxy settings remain in effect.
 These `CI_PIP_*` settings apply only to the Job's pip install. They are not
 passed into Docker build arguments or persisted into the production image.
 The Dockerfile keeps its own cached/offline dependency installation and logs
-the Docker pip index host for online installs. Debian mirror variables affect
-APT only and are loaded later in the Docker verification step.
+the Docker pip index host for online installs. The Alpine mirror variable affects
+APK only and are loaded later in the Docker verification step.
 
 If dependency installation fails, the always() cleanup step still executes.
 It skips the Python/PyYAML cleanup script when no CI Compose manifest exists,