bootstrap: Add Apple Silicon toolchain support

[boinger]

Problem

On Apple Silicon Macs, python utils/build.py --preset coreone --build-type release fails during cmake configure:

dyld[...]: Library not loaded: /usr/local/opt/zstd/lib/libzstd.1.dylib
  Referenced from: <...>/gcc-arm-none-eabi-13.2.1/libexec/gcc/arm-none-eabi/13.2.1/cc1
  Reason: tried: ... (no such file)
arm-none-eabi-gcc: internal compiler error: Abort trap: 6 signal terminated program cc1

The bootstrapped gcc-arm-none-eabi-13.2.1 is the Intel macOS build (darwin-x86_64). On Apple Silicon it runs under Rosetta, and its cc1 has hardcoded dylib references to /usr/local/opt/zstd/lib/ (Intel Homebrew path). This path doesn't exist on arm64 systems — Homebrew installs under /opt/homebrew/ — and even symlinking can't help because Rosetta requires x86_64 libraries while Homebrew's zstd is native arm64.

Fix

Two changes to utils/bootstrap.py:

(1) Add a native arm64 Darwin toolchain URL. bootstrap.py already supports per-architecture URLs (Linux-aarch64 is present). The selection logic at bootstrap.py:244-248 resolves platform.system()-platform.machine() first, falling back to platform.system() if absent. On Apple Silicon, platform.machine() returns arm64, so the lookup produces Darwin-arm64 — which has no entry, falling back to Darwin (the Intel binary). Adding the Darwin-arm64 entry lets the lookup resolve to ARM's native arm64 build.

(2) Fix a typo in the existing Darwin URL. The URL ends with .tar.xzg (extra g). The file at that URL is not something ARM actually hosts directly — curl -I shows ARM's developer.arm.com returns 302 and silently redirects .tar.xzg to the canonical .tar.xz on their Azure Blob CDN. So the current URL "works" only because of ARM's lenient URL routing. The extraction code at bootstrap.py:177-179 has accommodated the typo by including 'tar.xzg' in the valid-extension list for the endswith check. This is a latent bug: if ARM ever tightens URL routing, the Darwin build would break on both Intel and arm64 hosts.

 'gcc-arm-none-eabi': {
     'version': '13.2.1',
     'url': {
         'Linux': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz',
         'Linux-aarch64': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-aarch64-arm-none-eabi.tar.xz',
         'Windows': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-mingw-w64-i686-arm-none-eabi.zip',
-        'Darwin': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.tar.xzg',
+        'Darwin': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-darwin-x86_64-arm-none-eabi.tar.xz',
+        'Darwin-arm64': 'https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.tar.xz',
     }
 },

No changes needed downstream: the extraction logic (find_single_subdir + shutil.move) normalizes the archive's top-level directory to gcc-arm-none-eabi-13.2.1/ regardless of the archive name, so cmake and other consumers are arch-agnostic.

Verified end-to-end

Tested on macOS 26.5 beta (Build 25F5042g, Apple Silicon M4 Max) from a pristine state:

• Fresh branch off upstream/master (no other changes)
• Wiped .dependencies/gcc-arm-none-eabi-* and build/
• No DYLD_* env vars, no Intel Homebrew, no workarounds

Result:

Extracting arm-gnu-toolchain-13.2.rel1-darwin-arm64-arm-none-eabi.tar.xz done
...
Building finished: 2 success, 0 failure(s).
 coreone_release_boot   SUCCESS
 coreone_release_noboot SUCCESS

Produced coreone_release_boot.bbf (4.1MB). Cross-compiled output is equivalent to an x86_64 host build (136-byte .text delta, expected compiler-host noise).