fix(docker): revert builder base from rust:alpine to rust:latest

[muralidhar-challa]

Summary

Every build failure since the Alpine builder switch (2h QEMU hang → stale cache ABI mismatch → host/target CC mixup → UBSan symbol relocation) traces back to one root cause, confirmed via web research: rust-lang/cargo#7563. *-unknown-linux-musl targets default to +crt-static, which is fundamentally incompatible with proc-macro crates (dylib-style loading) on a musl host. sqlx-macros must run natively during compilation regardless of the cross --target requested for the final binary, and that host-native build is broken by this cargo/rustc limitation on Alpine — no amount of CC/linker wrapper configuration fixes it, since the problem is the host toolchain itself.

On a glibc host (rust:latest), the host triple (x86_64-unknown-linux-gnu) never touches musl or the zig wrapper at all — proc-macros build natively against glibc, and only the actual --target musl artifacts (compiled via zig) end up statically linked. This is exactly what the Dockerfile did for weeks (PRs #1-8) before the Alpine switch.

Important: this does not affect the shipped artifact. The builder's own base image is a throwaway compile-time container; the final uc-server binary is still cross-compiled via --target x86_64/aarch64-unknown-linux-musl and the final stage is still FROM scratch. Verified locally: file on the built binary confirms statically linked, stripped — still a fully static musl binary, still runs on Alpine or anywhere else with no libc present.

Test plan

• Local cold-cache build for amd64 completes cleanly (previously failed consistently on Alpine with an UBSan symbol relocation error)
• file on the resulting binary confirms it's statically linked (no glibc/dynamic dependency leaked into the shipped artifact)
• CI run on this PR (fmt/clippy/test) passes
• Once merged, push-to-main build actually completes for both amd64 and arm64