ci: parallel builds + pre-built sidecar binaries

[Nic-dorman]

Summary

Optimise the release workflow to cut build times from ~50 minutes to ~19 minutes by addressing two bottlenecks:

Change	Before	After	Saving
Windows build	Sequential (waits ~21min for Linux/macOS)	Parallel (starts immediately)	~21 min
Sidecar binary	Built from source (git clone + cargo build --release) ~10min/platform	Downloaded pre-built from ant-client releases ~10s/platform	~10 min/platform
Total wall clock	~50 min	~19 min	~31 min

Before: sequential pipeline

0:00 ─── Linux + macOS (parallel) ───────────────────── 21min
          ├─ clone ant-client + cargo build sidecar        ~9min
          └─ tauri build + bundle                          ~11min

21:00 ── Windows (waits for above) ──────────────────── 28min
          ├─ clone ant-client + cargo build sidecar        ~10min
          └─ tauri build + sign + bundle MSI               ~18min

49:00 ── merge latest.json ─────────────────────────── <1min

After: parallel pipeline

0:00 ── create-release (lightweight) ────────────────── <1min

0:01 ┬─ Linux ──────────────────────── ~12min
     ├─ macOS aarch64 ──────────────── ~12min    ALL PARALLEL
     ├─ macOS x86_64 ───────────────── ~12min
     └─ Windows (signed MSI) ──────── ~19min

19:00 ── merge latest.json ─────────────────────────── <1min

What changed

1. Parallel Windows build

Windows previously had needs: [build-linux-macos] because tauri-action created the draft release as a side effect, and Windows needed the release to exist for gh release upload.

Fix: a new lightweight create-release job creates the draft release first (via GitHub API), then passes the release_id to tauri-action via its releaseId input. All 4 platform builds now depend only on create-release and run in parallel.

2. Pre-built sidecar binaries

The sidecar step previously cloned WithAutonomi/ant-client and ran cargo build --release -p ant-cli (~10 min per platform). But ant-client already publishes pre-built binaries for all targets in its GitHub releases.

Now the workflow downloads the matching archive from ant-client releases (~10 seconds), extracts the ant binary, and places it in src-tauri/binaries/ for Tauri to bundle.

Target mapping:

Tauri target	ant-client asset	Format
aarch64-apple-darwin	aarch64-apple-darwin	tar.gz
x86_64-apple-darwin	x86_64-apple-darwin	tar.gz
x86_64-unknown-linux-gnu	x86_64-unknown-linux-musl	tar.gz
x86_64-pc-windows-msvc	x86_64-pc-windows-msvc	zip

Note: Linux uses the musl build (statically linked, works on glibc systems).

3. Configurable ant version (.ant-version)

A new .ant-version file controls which ant-client release to bundle. This allows pinning to a specific version for testing new node features ahead of a formal release.

Resolution priority:

1. workflow_dispatch input ant_version (for one-off test builds from the Actions tab)
2. .ant-version file in the repo (version-controlled, visible in PRs)
3. Falls back to latest if neither is set

Examples:

# Use latest ant-client release (default)
echo "latest" > .ant-version

# Pin to a specific pre-release for testing
echo "ant-cli-v0.1.2-rc.17" > .ant-version

# Or trigger a manual build from Actions tab with a specific version
# without committing anything

Test plan

• Trigger a release build and verify all 4 platforms build successfully
• Verify the draft release has all expected artifacts (DMG, AppImage, MSI, updater sigs)
• Verify latest.json has all platform entries after update-latest-json completes
• Test workflow_dispatch with a specific ant_version input
• Verify .ant-version file with a pinned tag works correctly
• Smoke test installed app on each platform — daemon starts, nodes work

🤖 Generated with Claude Code