Use musl codex-acp binaries for Linux

[yhn112]

Summary

Switch the codex-acp Linux registry targets from the GNU builds to the existing musl builds:

• linux-aarch64: aarch64-unknown-linux-gnu -> aarch64-unknown-linux-musl
• linux-x86_64: x86_64-unknown-linux-gnu -> x86_64-unknown-linux-musl

Why

Zed now resolves Codex ACP through the ACP registry, and the current registry entry maps the generic Linux targets to GNU binaries. Those binaries require newer glibc/OpenSSL runtime libraries and fail on older but still common remote/devcontainer environments such as Ubuntu 20.04 and Rocky/RHEL 8 with errors like:

libssl.so.3: cannot open shared object file
GLIBC_2.32 not found
GLIBC_2.34 not found

The official codex-acp releases already publish musl artifacts for both Linux architectures. Since the current registry schema has one generic linux-* target per architecture and does not distinguish gnu vs musl, using the musl artifacts is the more portable default until libc-qualified Linux targets or runtime fallback are available.

This is the registry-level equivalent of zed-industries/zed#49420, which was closed after Zed moved Codex ACP resolution to the registry.

Refs zed-industries/codex-acp#208
Refs zed-industries/zed#49420

Validation

• uv run --with jsonschema .github/workflows/build_registry.py --dry-run
• uv run .github/workflows/update_versions.py --agents codex-acp --json
• git diff --check

[yhn112]

One note on scope/trade-offs: I do not think this is the ideal long-term shape for Linux targets. This PR is intended as a small compatibility fix within the current registry schema, where each Linux architecture has a single generic target.

The downside is that this makes the musl artifact the default for all Linux users instead of preserving a separate GNU default. In principle, that trades some native glibc/system-library integration for broader runtime portability. For codex-acp specifically, I do not see an obvious critical downside for newer Linux systems, while this change should immediately improve things for me and for other users on older glibc/OpenSSL environments such as Ubuntu 20.04 and Rocky/RHEL 8.

Architecturally, it would probably be better for the registry and clients to support libc-qualified Linux targets, e.g. GNU vs musl, plus explicit selection/fallback behavior in clients. If that direction seems useful to maintainers, I can try to work on those follow-up changes in the foreseeable future.