fix(linux/build): systemd-in-container build host (M1.1)

Run #4258 cleared the systemctl shim only to die two seconds later on
the *next* expectation derivative-maker has of a real systemd host:
its sources.list points at http://127.0.0.1:9977/debian (the approx
package-cache socket-activated by systemd) and apt-get update could
not reach the daemon because nothing was actually started by the
no-op shim:

    Err:1 http://127.0.0.1:9977/debian trixie InRelease
      Could not connect to 127.0.0.1:9977 (127.0.0.1).
      - connect (111: Connection refused)

Whack-a-mole'ing each service derivative-maker tries to start (approx
today, then journald, then systemd-logind, then who-knows-what
tomorrow) is going to keep failing for a while — derivative-maker is
fundamentally designed for a real systemd-managed Debian host. The
container pattern upstream itself ships
(linux/build/derivative-maker/docker/) runs systemd as PID 1 inside
the container; this commit adopts that approach.

Architecture:

  - PID 1 in the build container is now systemd. Upstream's vendored
    entrypoint.sh records the user-supplied command into
    /etc/docker-entrypoint-cmd, captures env into
    /etc/docker-entrypoint-env, masks irrelevant units, and execs
    systemd. systemd boots, docker-entrypoint.service runs the
    command, docker-entrypoint-stop.sh propagates the exit code via
    `systemctl exit <code>` so the container exits with the right
    status.

  - The four entrypoint files (entrypoint.sh,
    docker-entrypoint.service / .target, docker-entrypoint-stop.sh)
    are vendored at linux/build/docker/systemd-entrypoint/ rather
    than COPY'd from the submodule path — Docker build context can
    only reach below itself, and bumping is tracked in that dir's
    README.

  - Container runtime now requires --cgroupns=host, --tmpfs /run,
    --tmpfs /run/lock, and -v /sys/fs/cgroup:/sys/fs/cgroup:rw so
    systemd can manage cgroups properly. -t allocates a TTY,
    satisfying entrypoint.sh's `[ ! -t 0 ] && exit 1` check in CI
    where stdin is otherwise /dev/null.

  - User renamed builder → user (uid 1000, passwordless sudo) to
    match upstream's USER=user / HOME=/home/user convention. chown
    in build.sh now uses uid 1000:1000 so it's name-agnostic.

  - Image package list grew to match upstream's
    derivative-maker-docker-setup (sq stack + dbus + approx + the
    rest) plus our ISO toolchain (live-build / debootstrap / xorriso
    / squashfs-tools / etc.). Snapshot.debian.org pinning is
    preserved (same APT_SNAPSHOT_URL, two-phase install pattern).

Verified:

  Smoke test on 10.0.0.51 — `docker run --rm --privileged
  --cgroupns=host --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:...:rw
  -t <image> /bin/bash -c 'echo OK'` — booted systemd, ran the
  command via docker-entrypoint.service, captured the output, shut
  down filesystems and exited cleanly.

build.sh BUILDER_IMAGE pin → sha256:dc9dd29d…8811. Image rebuilt
natively on 10.0.0.51, pushed to docker-registry.silverlabs.uk.

The systemctl shim is removed by virtue of the Dockerfile rewrite —
real systemd makes it unnecessary. The previous "iter6 / iter7"
intermediate digests stay in the registry until we GC; the live one
is m1.1-iter8-systemd.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

linux/build/scripts/build-inner.sh

@@ -2,13 +2,16 @@
 # SilverMetal Linux — inner build step.
 #
 # Runs *inside* the silvermetal-builder container, as the unprivileged
-# `builder` user. build.sh sets up the container, chowns the workspace,
-# and runuser's into here. derivative-maker takes it from there and uses
-# sudo internally for its privileged operations.
+# `user` (uid 1000). build.sh's docker-run cmd chowns the workspace and
+# sudoes here. The container's PID 1 is systemd (upstream's
+# systemd-in-container pattern), so any `systemctl` calls derivative-
+# maker makes — to start approx, daemon-reload, etc. — actually do
+# what they're supposed to. derivative-maker uses sudo internally for
+# its privileged ops.
 #
 # Why this is its own file:
 #   The previous incarnation lived as a heredoc inside build.sh's docker
-#   run command. Once we needed to drop privileges from root to builder,
+#   run command. Once we needed to drop privileges from root to user,
 #   the nested-heredoc / nested-quoting situation became unreadable; a
 #   plain script with normal quoting is far easier to maintain.
 #

linux/build/scripts/build.sh

@@ -32,7 +32,7 @@ cd "${REPO_ROOT}"
 # outside the LAN — it's the entry that fleet-wide /etc/docker/daemon.json
 # registers as an insecure-registry. The host-style "docker-registry:5000"
 # is *not* DNS-resolvable; do not use it.
-BUILDER_IMAGE="${BUILDER_IMAGE:-docker-registry.silverlabs.uk/silvermetal-builder@sha256:70f160ab6084c49b81262e3625425848eb678c4b13175fb1b201cfb1fa075460}"
+BUILDER_IMAGE="${BUILDER_IMAGE:-docker-registry.silverlabs.uk/silvermetal-builder@sha256:dc9dd29df4bee54807aee5bb2605b400754cba86db5343b4947a81a7ecea8811}"
 
 if [[ "${BUILDER_IMAGE}" != *"@sha256:"* ]]; then
     echo "build.sh: BUILDER_IMAGE must be pinned by digest, got: ${BUILDER_IMAGE}" >&2
@@ -105,11 +105,36 @@ else
 fi
 
 # --- Run the build inside the container ------------------------------------
-# --privileged is required because live-build mounts loop devices and chroots.
-# --network=host lets the container reach snapshot.debian.org without us
-# fighting CI proxy config; tighten if/when that becomes a concern.
+# This is a systemd-in-container build host. Upstream Kicksecure's
+# derivative-maker assumes a real systemd-managed Debian — its build steps
+# call `systemctl restart approx-derivative-maker.socket`,
+# `systemctl daemon-reload`, etc. and depend on those services *actually*
+# running. Without systemd as PID 1 we'd be playing whack-a-mole with
+# every service derivative-maker starts.
+#
+# Required runtime flags for systemd-in-container:
+#   --privileged           live-build needs loop devices + chroot mounts
+#   --cgroupns=host        systemd needs to manage cgroups; with its own
+#                          namespace it can't see the host hierarchy
+#   --tmpfs /run, /run/lock  systemd writes runtime state here
+#   -v /sys/fs/cgroup:rw   the cgroup tree systemd manages
+#   -t                     entrypoint.sh requires a TTY (it `exit 1`s on
+#                          stdin not a tty); allocating one keeps that
+#                          path happy in CI too where stdin is otherwise
+#                          /dev/null
+#
+# `tail -f /dev/null` is NOT used — control flow goes through systemd:
+# entrypoint.sh writes the user command to /etc/docker-entrypoint-cmd,
+# execs systemd, systemd boots docker-entrypoint.service which runs the
+# command, and docker-entrypoint-stop.sh propagates exit code via
+# `systemctl exit <code>` so the container exits with the right status.
 docker run --rm --privileged \
+    --cgroupns=host \
+    --tmpfs /run \
+    --tmpfs /run/lock \
+    -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
     --network=host \
+    -t \
     "${BIND_ARGS[@]}" \
     -e SOURCE_DATE_EPOCH \
     -e SNAPSHOT_TIMESTAMP \
@@ -118,17 +143,20 @@ docker run --rm --privileged \
     -e TZ=UTC \
     -e REPO_ROOT="${REPO_ROOT}" \
     -e BUILD_DIR="${BUILD_DIR}" \
-    -w "${REPO_ROOT}" \
     "${BUILDER_IMAGE}" \
-    bash -euo pipefail -c '
-        # derivative-maker refuses to run as root (it uses sudo internally
-        # for the privileged ops). Hand the workspace ownership to the
-        # unprivileged builder user (uid 1000, created in the Dockerfile
-        # with passwordless sudo), then drop privs and let build-inner.sh
-        # do the actual work.
-        chown -R builder:builder "${REPO_ROOT}" "${BUILD_DIR}"
-        runuser -u builder -- "${REPO_ROOT}/linux/build/scripts/build-inner.sh"
-    ' || { echo "build.sh: derivative-maker failed"; exit 3; }
+    bash -c '
+        # docker-entrypoint.service runs this as root via systemd, with
+        # the env vars captured by entrypoint.sh into
+        # /etc/docker-entrypoint-env. We hand workspace ownership to the
+        # unprivileged user (uid 1000), then sudo into it for the
+        # derivative-maker invocation. derivative-maker uses sudo
+        # internally for the bits that need root.
+        set -e
+        chown -R 1000:1000 "${REPO_ROOT}" "${BUILD_DIR}"
+        exec sudo --non-interactive --preserve-env -u user -- \
+            "${REPO_ROOT}/linux/build/scripts/build-inner.sh"
+    ' \
+    || { echo "build.sh: derivative-maker failed"; exit 3; }
 
 # --- Hash artefacts ---------------------------------------------------------
 # Run hashing on the host (not in the container) so a busted container image