fix(image): build against glibc until musl can link inside the builder

[BryanFRD]

The image has been unbuildable since #329, so v1.16.2 and v1.16.3 both went out without one. This puts the glibc build back.

#331 did not land this. Its last push recreated a branch auto-merge had already deleted, so the revert commit sat on a branch nobody merged while the PR closed on the commit before it. Main kept the musl Dockerfile, cut v1.16.3 from it, and the image build failed again. Same content as #331 described, on a branch that exists.

Why musl is going away for now, from #331 and #327:

descriptors: 1024 soft, 1024 hard
error: sub-compilation of compiler_rt failed
  note: unable to load source: ProcessFdQuotaExceeded

zig wants more file descriptors than the build container has, and the hard limit is 1024, so nothing inside the Dockerfile can raise it. The limit belongs to the container the build engine creates, which lives in the org's reusable workflow.

Local builds could never see it: Docker Desktop gives a container 1048576 descriptors, so the musl Dockerfile built and served here every time, on both architectures, at 4.4 MB.

Verified before pushing: builds, and answers /health when run with --ulimit nofile=1024:1024, which is the limit that breaks the other one. 12.8 MB.

set -eu on the build step stays, because it is what turned a silent empty layer into a legible failure in the first place. #327 is reopened with the diagnosis and the two candidate routes.

[ferrfleet]

Checked the parts that usually break a glibc revert, and they line up:

• Builder is rust:1.88-bookworm (glibc 2.36) and the runtime is distroless/cc-debian12 (also 2.36), so the dynamic link is satisfiable on both stages. A builder on trixie would have been the failure mode here, and it isn't one.
• libc6-dev-arm64-cross on bookworm is the same 2.36, so the cross half lands on the same floor.
• CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER is the right variable name, and cc-rs defaults to aarch64-linux-gnu-gcc for that target on its own, so ring and zstd get a target compiler without further wiring.
• The zig removal is complete: nothing outside the Dockerfile referenced ZIG_VERSION, ZIGBUILD_VERSION or the cache dirs, so no renovate rule or workflow is left pointing at something that no longer exists.

One thing I could not confirm: the arm64 cross-compile is only exercised by Build without publishing, and that job was still running when I read the PR. It is the half no laptop can try, and the 12.8 MB figure in the description reads as amd64 only. Worth waiting for green rather than merging on the amd64 evidence.

Nit: docs/performance.md:43 now says the opposite of what ships. "The image ships a musl binary rather than the glibc one this table was first measured with" was written to explain why the table's numbers came from a different build than the image; with this merged, the table and the image agree again, and the paragraph should say so instead of being deleted, since the four-sample comparison it reports is still the reason nobody needs to worry about the switch either way. The same premise is stated in bench/throughput.sh ("The image ships a musl binary") and in .github/workflows/bench.yml ("the image ships musl and musl allocates differently under threads"), where it is the stated justification for benching both rows. The rationale inverts rather than disappears: the host/gnu row is now the shipped one and the musl row is the release-tarball one, so the matrix still earns its place. Not blocking, and clearly follow-up work rather than something to pile onto an image fix.

README.md and docs/why.md say "one statically linked binary, a distroless image". That stays true of the release tarballs, which are still musl, so I would leave it.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}