fix(docker): cross-compile BoringSSL for the arm64 image leg

The v0.35.0 multi-arch image build failed linking every binary for
aarch64:

    ld: libbtls_sys.rlib(base64.cc.o): Relocations in generic ELF (EM: 62)
    ld: libbtls_sys.rlib: error adding symbols: file in wrong format

EM 62 is x86-64: btls-sys compiled its vendored BoringSSL for the HOST
while the Rust half targeted aarch64. btls-sys does apply an aarch64
CMAKE_TOOLCHAIN_FILE, but that file sets only CMAKE_SYSTEM_NAME and
CMAKE_SYSTEM_PROCESSOR and then says "Rely on environment variables to
set the compiler and include paths". Because a toolchain file is present
the cmake crate does not inject CMAKE_C_COMPILER either, so CMake picked
the host cc.

Setting the per-target compiler variables the cc crate reads is what
reaches CMake through it. Verified in a bookworm container with the same
cross toolchain the image installs: all three binaries now link as
"ELF 64-bit LSB pie executable, ARM aarch64", and the objects inside
libbtls_sys.rlib are aarch64 rather than x86-64.

The names are target-suffixed, so the amd64 leg ignores them.

Note for anyone reading the image contents: the three packages are built
in one cargo invocation, so the impersonated feature enabled for
crw-server unifies onto the shared crw-renderer and the `crw` CLI in the
image links BoringSSL too. The published release binaries are built
separately with no features and are unaffected.

Author: us

Dockerfile

@@ -84,7 +84,19 @@ RUN cargo install cargo-chef --locked --version 0.1.77
 #     of crw-server (aws-lc-sys + full graph) needs several GB and OOM-killed
 #     the build (#90). thin LTO + 16 CGUs: far lower peak memory, faster link,
 #     negligible runtime difference.
+#   - C/C++ cross compilers for the aarch64 target. btls-sys (the vendored
+#     BoringSSL behind wreq) applies its own CMAKE_TOOLCHAIN_FILE for aarch64,
+#     and that file sets only CMAKE_SYSTEM_NAME/PROCESSOR: "Rely on environment
+#     variables to set the compiler and include paths." Because a toolchain file
+#     is present, the cmake crate does not inject CMAKE_C_COMPILER either, so
+#     CMake fell back to the HOST cc and produced x86-64 objects. The aarch64
+#     link then died with "Relocations in generic ELF (EM: 62)" on
+#     libbtls_sys.rlib. These two are what the cc crate reads for the target,
+#     and they reach CMake through it. They are per-target names, so the amd64
+#     leg ignores them.
 ENV CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc \
+    CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc \
+    CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++ \
     CARGO_PROFILE_RELEASE_LTO=thin \
     CARGO_PROFILE_RELEASE_CODEGEN_UNITS=16