Build a native arm64 image instead of emulating amd64

[aleksanderllada]

Summary

An arm64 image built from source SIGILLs on anything short of Graviton3+, because .cargo/config.toml pins -C target-cpu=neoverse-512tvb for aarch64-unknown-linux-gnu. DOCKER.md worked around it by telling Apple Silicon users to build --platform linux/amd64 and emulate:

- On Apple Silicon (M-series Macs), builds must target `linux/amd64` due to Graviton-specific
  compiler flags in `.cargo/config.toml` for `aarch64-unknown-linux-gnu`

This builds natively instead. docker build -f lore-server/Dockerfile . now produces a baseline armv8-a image on Apple Silicon, and --build-arg ARM64_TARGET_CPU=neoverse-512tvb opts back into the tuning for a Graviton deployment.

Two things worth a reviewer's attention

Overriding the pin needs RUSTFLAGS specifically, not CARGO_TARGET_<triple>_RUSTFLAGS. The latter is only another source for the same config key, and cargo joins config arrays — the config's -C target-cpu would survive and the build would still fault. RUSTFLAGS replaces [build] and [target.*] outright, which is why the flags are restated in full rather than appended to.

RUSTFLAGS does not reach a C compiler. lore-base/build.rs pins the same -mcpu for its cc build of rpmalloc, so the Rust half alone is not enough. That flag raises the architecture floor as well as the tuning — disassembling both builds with GCC 14:

only in the tuned build:  casa casal casl ldadd ldapr madd stlur

No SVE, so Apple Silicon was never at risk from the C half. But stlur is FEAT_LRCPC2 (armv8.4) and ldapr is armv8.3, and Neoverse N1 has neither — so an otherwise-baseline image would still have faulted in the allocator on Ampere Altra and Graviton2. build.rs now reads LORE_ARM64_TARGET_CPU, defaulting to the value it hardcoded so nothing else changes, and the Dockerfile passes the choice through.

Also here: EXPOSE defaults to TCP, so it was not declaring the QUIC listener sharing port 41337 — docker run -P left it unreachable.

Test evidence

• Disassembled rpmalloc both ways on linux/arm64; with the tuning off the allocator is clean armv8-a, and the instructions above appear only with it on.
• Built the image natively on an M3 Max and ran it — see the comment below for the result.
• cargo fmt and cargo clippy clean on build.rs. (Clippy reports three pre-existing errors in lore-revision/src/{stage,state}.rs, untouched here and present on main.)

Note

Split out of #180, which touches the same two sections of DOCKER.md — whichever merges second will need a small conflict resolution.

[aleksanderllada]

Built and ran on an M3 Max, which is the case main documents as impossible:

$ docker build -f lore-server/Dockerfile -t loreserver:arm64-native .
$ docker image inspect loreserver:arm64-native --format '{{.Os}}/{{.Architecture}}'
linux/arm64
$ docker run --rm loreserver:arm64-native --version
loreserver 0.9.1-nightly

No --platform override, no emulation, exit 0.

Disassembled the shipped binary rather than trusting the flags:

stlur (armv8.4):  0
ldapr (armv8.3):  0
SVE:              0
casa/casal/ldadd: 2 each

Those last ones look like a hole in the baseline claim but are not. Every occurrence sits inside an __aarch64_* helper:

casa   <__aarch64_cas4_acq>
casal  <__aarch64_cas8_acq_rel>
ldadd  <__aarch64_ldadd8_relax>

That is rustc's outline-atomics, on by default for aarch64-unknown-linux-gnu: the helpers branch on __aarch64_have_lse_atomics at runtime and fall back to LL/SC, so they are safe on a CPU without LSE. The binary really is armv8.0-clean.

Not verified here: that --build-arg ARM64_TARGET_CPU=neoverse-512tvb produces a binary that faults on non-Graviton hardware. The rpmalloc disassembly in the description shows the C half taking the tuning, and the Rust half is the pre-existing .cargo/config.toml behaviour this works around.