[CMGS]

Two cleanups in boot/Dockerfile that the post-#447 audit found (#455 listed them as a decision because they rebuild the image).

• Kernel mirror chain: the comment said cdn.kernel.org 404s the tarball paths; it serves them again (HTTP 200 for v6.x/linux-6.18.37.tar.xz, checked today), and since KERNEL_MIRROR defaults to cdn the loop tried it twice. The hard-coded cdn entry is gone and the comment states the chain as it is: KERNEL_MIRROR, kernel.org's edge mirror, the rsync mirror. The SHA256 check is unchanged.
• Init build: init/rust-toolchain.toml lists rustfmt and clippy, which the rust base image does not carry, so every uncached build synced the channel and downloaded both components and used neither. The build now drops the components line from its copy of the file; the file still pins the compiler, and local development and CI keep both components.

Evidence

• docker build --no-cache --target initbuild boot (linux/arm64): the old Dockerfile logs info: syncing channel updates, info: latest update on 2026-10-15 for version 1.99.1 and info: downloading 2 components; the new one logs no rustup network step, and sandbox-init builds in 3.4 s.
• The edited fetch loop, run in the pinned debian base with the repo's kernel/SHA256: the default mirror fetches and verifies (/tmp/linux.tar.xz: OK); with a first mirror that answers 404 it falls through to the edge mirror and verifies.
• Not run locally: the full kernel build. The kernel config, source and hash are unchanged.

Cost

Merging to main matches the images workflow's boot/** path filter, so it rebuilds the boot carrier on both native runners and then the os-images that base on it. The kernel and initramfs contents are unchanged. silkd/Dockerfile has the same toolchain-component pattern; it is left alone here because changing it rebuilds silkd and every guest image too.