build(docker): cross-compile the musl build instead of emulating it

The scratch runtime as first written dropped the --platform pin from the musl
builder, so arm64 compiled under QEMU. I estimated 20-45 minutes for that by
extrapolating from Nexus, which builds the same way. Nexus's tree is far
smaller; ours ran 6h42m and was killed still compiling. The estimate was
presented as informed and was not — it should have been "I have not measured
this".

Cross-compiled with cargo-zigbuild the same build takes 10 minutes for both
architectures. Both numbers are now in the Dockerfile so nobody repeats the
emulation thinking it is equivalent.

zig rather than clang because Rust links musl targets with rustup's own
self-contained CRT, so pure-Rust code cross-compiles unaided — the gap is
aws-lc-sys and zstd-sys, which are C. `xx-info triple` resolves musl targets to
-linux-gnu, and clang against Debian's arm64 musl sysroot fails on a missing
crtend.o. `zig cc` ships a complete cross toolchain, which is exactly what was
missing.

Three failures on the way, each fixed rather than worked around:

- The toolchain shared a stage with the compile, so when crates.io served 503s
  mid-fetch the whole thing restarted. It is now its own stage, and
  cargo-zigbuild arrives as the project's prebuilt binary instead of
  `cargo install --locked`, which compiled a tool from source on the critical
  path of every build. That stage now takes 20 seconds.

- Both architectures shared the cargo registry cache mount without a sharing
  mode, so they raced unpacking into the same directory and died with
  "failed to unpack cfg-if: File exists". Now `sharing=locked`.

- The static-link gate was written `... || { echo "not statically linked"; }`,
  which catches every failure in the chain. When the compile failed the binary
  never existed, and the gate still blamed linkage — a check reporting the
  wrong cause with confidence. Now an `if !` around only what it tests.

Also pins pnpm. The dashboard stage installed `pnpm@latest` over node:20, and
pnpm's latest started requiring Node >= 22.13 (it imports node:sqlite), so the
build broke with ERR_UNKNOWN_BUILTIN_MODULE. Nothing here changed; the outside
world did. Every workflow already pinned pnpm@10 and dashboard/package.json
declares packageManager pnpm@10.15.1 — the Dockerfile was the one place still
floating.

Published and verified: 3.7.1 and 3.7.1-fastembed, both amd64+arm64. The
default image scans 0 packages / 0 vulnerabilities and boots healthy from the
registry; the arm64 fastembed binary runs (`vectorizer 3.7.1`), which is the
check 3.6.0 failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: andrehrferreira

Dockerfile

@@ -172,8 +172,16 @@ RUN cargo chef prepare --recipe-path recipe.json
 FROM node:20-bookworm AS dashboard-builder
 WORKDIR /dashboard
 
-# Install pnpm
-RUN npm install -g pnpm@latest
+# Install pnpm.
+#
+# PINNED, and not to `@latest`. Every workflow already pins `pnpm@10` and
+# `dashboard/package.json` declares `packageManager: pnpm@10.15.1`; this line
+# was the one place still floating, and it broke the moment pnpm's latest
+# started requiring Node >= 22.13 — it imports `node:sqlite`, which does not
+# exist on the node:20 base, so `pnpm install` died with
+# ERR_UNKNOWN_BUILTIN_MODULE. Nothing in this repo changed; the outside world
+# did.
+RUN npm install -g pnpm@10.15.1
 
 # Copy dashboard files
 COPY dashboard/package.json dashboard/pnpm-lock.yaml dashboard/pnpm-workspace.yaml ./
@@ -393,20 +401,52 @@ FROM busybox:stable-musl AS busybox
 # to `-linux-gnu` (`xx-info triple`), and pointing clang at Debian's arm64
 # musl sysroot fails on missing `crtend.o`, so cross-compiling this would mean
 # hand-assembling a toolchain rather than using one.
-FROM rust:1.95-slim-trixie AS builder-musl
+# ----------------------------------------------------------------------------
+# Cross-compilation toolchain — its own stage on purpose
+# ----------------------------------------------------------------------------
+# Split out so a network hiccup while fetching it cannot invalidate the
+# expensive compile layer below, and vice versa. That is not hypothetical: a
+# publish attempt died here when crates.io served 503s from its CDN mid-fetch,
+# and because the toolchain shared a stage with the build, the whole thing had
+# to start over.
+#
+# `cargo-zigbuild` arrives as the project's own prebuilt binary rather than
+# `cargo install --locked`, which compiled it from source on every build —
+# minutes of work, and a crates.io dependency, both on the critical path of
+# something that is just a tool.
+FROM --platform=${BUILDPLATFORM:-linux/amd64} debian:trixie-slim AS zig-toolchain
+ARG ZIG_VERSION=0.13.0
+ARG CARGO_ZIGBUILD_VERSION=0.23.3
+RUN apt-get update     && apt-get install -y --no-install-recommends curl xz-utils ca-certificates     && rm -rf /var/lib/apt/lists/*     && curl -sSL --retry 5 --retry-all-errors         "https://ziglang.org/download/${ZIG_VERSION}/zig-linux-x86_64-${ZIG_VERSION}.tar.xz"        | tar -xJ -C /opt     && mv "/opt/zig-linux-x86_64-${ZIG_VERSION}" /opt/zig     && curl -sSL --retry 5 --retry-all-errors -o /tmp/czb.tar.xz         "https://github.com/rust-cross/cargo-zigbuild/releases/download/v${CARGO_ZIGBUILD_VERSION}/cargo-zigbuild-x86_64-unknown-linux-musl.tar.xz"     && tar -xJf /tmp/czb.tar.xz -C /usr/local/bin --strip-components=1 "cargo-zigbuild-x86_64-unknown-linux-musl/cargo-zigbuild"     && rm /tmp/czb.tar.xz     && /opt/zig/zig version     && cargo-zigbuild --version
+
+# ----------------------------------------------------------------------------
+# STATIC MUSL BUILD
+# ----------------------------------------------------------------------------
+# Pinned to $BUILDPLATFORM and cross-compiled, NOT built per-target. That
+# distinction is the whole cost of this stage:
+#
+#   emulated arm64 (no --platform pin) : killed at 6h42m, still compiling
+#   cross-compiled with zig            : 7m05s
+#
+# Measured, after the first form was tried and abandoned. Nexus builds its
+# arm64 under emulation and lives with it; its tree is far smaller than this
+# one, so copying that choice without measuring was the mistake.
+#
+# Why zig rather than clang: Rust links musl targets with rustup's own
+# self-contained CRT, so pure-Rust code cross-compiles unaided — but
+# `aws-lc-sys` and `zstd-sys` are C and need a cross C compiler. `xx-info
+# triple` resolves musl targets to `-linux-gnu`, and clang against Debian's
+# arm64 musl sysroot fails on a missing `crtend.o`. `zig cc` ships a complete
+# cross toolchain for every target it supports, which is exactly the gap.
+FROM --platform=${BUILDPLATFORM:-linux/amd64} rust:1.95-slim-trixie AS builder-musl
 WORKDIR /vectorizer
 
+COPY --from=zig-toolchain /opt/zig /opt/zig
+COPY --from=zig-toolchain /usr/local/bin/cargo-zigbuild /usr/local/bin/cargo-zigbuild
+ENV PATH="/opt/zig:${PATH}"
+
 ARG TARGETARCH
-RUN apt-get update \
-    && apt-get install -y --no-install-recommends \
-       musl-tools clang lld cmake protobuf-compiler pkg-config file perl make \
-    && rm -rf /var/lib/apt/lists/* \
-    && case "${TARGETARCH:-amd64}" in \
-         amd64) TARGET_TRIPLE=x86_64-unknown-linux-musl ;; \
-         arm64) TARGET_TRIPLE=aarch64-unknown-linux-musl ;; \
-         *) echo "unsupported TARGETARCH '${TARGETARCH}'" >&2; exit 1 ;; \
-       esac \
-    && rustup target add "${TARGET_TRIPLE}"
+RUN apt-get update     && apt-get install -y --no-install-recommends        cmake protobuf-compiler pkg-config file perl make     && rm -rf /var/lib/apt/lists/*     && case "${TARGETARCH:-amd64}" in          amd64) TARGET_TRIPLE=x86_64-unknown-linux-musl ;;          arm64) TARGET_TRIPLE=aarch64-unknown-linux-musl ;;          *) echo "unsupported TARGETARCH '${TARGETARCH}'" >&2; exit 1 ;;        esac     && rustup target add "${TARGET_TRIPLE}"
 
 ARG PROFILE=release-docker
 ARG GIT_COMMIT_ID
@@ -424,20 +464,7 @@ COPY --from=dashboard-builder /dashboard/dist /vectorizer/dashboard/dist
 # would build fine here and then fail to exec in `scratch`, where there is no
 # loader. `ldd` is NOT usable for this — glibc's ldd prints "statically
 # linked" and exits 0 for static-PIE binaries, so it would pass either way.
-ENV CARGO_BUILD_JOBS=2
-RUN --mount=type=cache,target=/usr/local/cargo/registry \
-    unset OPENSSL_DIR OPENSSL_INCLUDE_DIR OPENSSL_LIB_DIR OPENSSL_STATIC; \
-    case "${TARGETARCH:-amd64}" in \
-      amd64) TARGET_TRIPLE=x86_64-unknown-linux-musl ;; \
-      arm64) TARGET_TRIPLE=aarch64-unknown-linux-musl ;; \
-    esac \
- && cargo build --profile "$PROFILE" --package vectorizer-server --bin vectorizer \
-      --no-default-features --target "$TARGET_TRIPLE" \
- && PROFILE_DIR=$(if [ "$PROFILE" = dev ]; then echo debug; else echo "$PROFILE"; fi) \
- && cp "target/${TARGET_TRIPLE}/${PROFILE_DIR}/vectorizer" /vectorizer-static \
- && file /vectorizer-static | grep -Eq 'static-pie linked|statically linked' \
- || { echo "::error::binary is not statically linked — it would not exec in scratch"; \
-      file /vectorizer-static; exit 1; }
+RUN --mount=type=cache,target=/usr/local/cargo/registry,sharing=locked     unset OPENSSL_DIR OPENSSL_INCLUDE_DIR OPENSSL_LIB_DIR OPENSSL_STATIC;     case "${TARGETARCH:-amd64}" in       amd64) TARGET_TRIPLE=x86_64-unknown-linux-musl ;;       arm64) TARGET_TRIPLE=aarch64-unknown-linux-musl ;;     esac  && cargo zigbuild --profile "$PROFILE" --package vectorizer-server --bin vectorizer       --no-default-features --target "$TARGET_TRIPLE"  && PROFILE_DIR=$(if [ "$PROFILE" = dev ]; then echo debug; else echo "$PROFILE"; fi)  && cp "target/${TARGET_TRIPLE}/${PROFILE_DIR}/vectorizer" /vectorizer-static  && if ! file /vectorizer-static | grep -Eq 'static-pie linked|statically linked'; then echo "::error::binary is not statically linked — it would not exec in scratch"; file /vectorizer-static; exit 1; fi
 
 # ============================================================================
 # USER PREP — throwaway stage, only text files survive into the runtime