ci: build release binaries with Nix

[SDAChess]

Summary

Replace the separate release binary build paths with one Nix-based artifact workflow. Build each platform binary once, then reuse those artifacts across packaging, smoke tests, and release publication.

Related Issue

Closes #1683

Changes

• Add a shared workflow that computes the release version once and passes it to all build jobs
• Build Linux CLI and sandbox binaries statically with musl
• Build Linux gateway and VM-driver binaries against glibc 2.28
• Normalize dynamic Linux binaries with standard interpreters and no Nix RPATH
• Build Apple Silicon CLI, gateway, and VM-driver binaries natively on macOS
• Build release binaries with cargo auditable and verify their embedded metadata with Syft
• Link Z3 statically into portable gateway and VM-driver artifacts
• Package binaries into target-specific tarballs
• Build the VM driver from the matching sandbox artifact and rolling VM runtime
• Reuse built artifacts in downstream packages, smoke tests, and release jobs
• Remove superseded Zig, Docker, and native binary build paths after migrating their callers

Testing

• mise run pre-commit passes
• actionlint passes for the binary workflow
• x86_64 Linux CLI builds as a static PIE with auditable metadata
• x86_64 Linux gateway builds with static Z3 and auditable metadata
• Gateway normalization removes its Nix RPATH and sets the standard Linux interpreter
• Gateway references no symbols newer than GLIBC 2.28
• ARM64 Linux build matrix passes in GitHub Actions
• Apple Silicon build matrix passes in GitHub Actions
• Sandbox-to-VM-driver artifact chain passes in GitHub Actions
• Downstream package and release smoke tests pass
• Unit tests added/updated (not applicable; workflow-only change)
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (not applicable; CI-only change)

[elezar]

Thanks @SDAChess.

One minor question. I assume a follow-up will be to start consuming these from other pipeline stages? Would it make sense to do that already to validate that the workflow works as expected?

[SDAChess]

Thanks @SDAChess.

One minor question. I assume a follow-up will be to start consuming these from other pipeline stages? Would it make sense to do that already to validate that the workflow works as expected?

I plan to add this in this pull request. It's not ready for review yet. I'll put it as draft...

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.