fix(python-multiversion-uv): derive broker arch from AVOCADO_SDK_TARGET

[bbrock25]

Summary

• The broker compile step detected the target arch by probing the SDK container's python3 (platform.machine()), assuming an x86_64 SDK host where only the target python is emulated via binfmt.
• On arm64 hosts (Apple Silicon), the SDK container is natively aarch64, so the probe returned aarch64 for every target — shipping an arm64 nats-server into qemux86-64 images. nats.service then failed with an exec format error (status=203/EXEC) and all three apps looped on ConnectionRefusedError against 127.0.0.1:4222, while the image otherwise built and booted cleanly.
• Resolve the arch from $AVOCADO_SDK_TARGET instead, matching the app compile scripts in this reference (whose comments document this exact host-vs-target trap).

Test plan

• On an Apple Silicon Mac, avocado build for qemux86-64: broker step logs nats-server ... for linux-amd64 and file broker/bin/nats-server reports x86-64 (previously ARM aarch64)
• avocado provision dev + avocado sdk run -iE vm dev: nats.service active, app314 logs pipeline_complete with the 3.11/3.12/3.14 chain
• aarch64 target build (raspberrypi5, same arm64 host): full build succeeds; broker step logs nats-server ... for linux-arm64 and file confirms ARM aarch64 for the broker binary, shipped interpreter, and numpy .sos

Note for reviewers: existing checkouts may have a stale wrong-arch binary cached at broker/bin/nats-server; broker-clean.sh (or a full clean) is needed once after this change.

🤖 Generated with Claude Code

[jetm]

Arch mapping is correct for the three supported targets (qemux86-64 -> amd64, raspberrypi4/5 -> arm64). Two things to fix before merge, inline: the new catch-all drops the old fail-loud default so a missing/empty AVOCADO_SDK_TARGET silently builds an arm64 broker (MEDIUM), and the comment's claim that this mirrors the app compile scripts is inaccurate.

[jetm]

This catch-all replaces the old explicit arm64 arm plus a fail-loud *) exit 1. With only set -e (no set -u), an unset or empty AVOCADO_SDK_TARGET falls through to arm64 - so if a CLI version doesn't export it into this compile hook (the sibling app-compile scripts never read AVOCADO_SDK_TARGET, so its presence here is an assumption worth confirming), a qemux86-64 build silently downloads the linux-arm64 nats-server and fails to exec on the x86_64 device at runtime, with no build-time error. That's a robustness regression vs the code being replaced. Suggest guarding with : "${AVOCADO_SDK_TARGET:?AVOCADO_SDK_TARGET not set}" and keeping a hard-fail *) for unrecognized targets (which also stops a future riscv / 32-bit-arm target from silently mapping to arm64). Mapping is otherwise correct for the three supported targets.

[jetm]

The comment says this derives arch "the same way the app compile scripts do," but none of them do - app311/app314 rely on uv autodetecting the arch inside the SDK container and app312 uses the system python3. The broker genuinely differs (it downloads a prebuilt GitHub binary, so it can't lean on uv autodetection), so the approach is fine - but the cited precedent doesn't exist, and the new comment ("runtime probes report the HOST arch") contradicts the old one it replaced ("the target python3 reports the real target arch"). Worth reconciling the rationale.