ci: Build static server binaries in CI

[ebendler]

What

This PR modifies the release action to produce and upload static binaries for the switchyard-server tool. It also updates all gh actions to their latest versions to ensure node24 compat for CI runners.

Why

Static binaries are needed so that switchyard can be packaged and used in places like agent plugins without having to haul in the whole Rust SDK.

Summary by CodeRabbit

• New Features

  • Added automated builds and release packaging for server binaries across Linux, macOS, and Windows.
  • Published binaries are smoke-tested, checksummed, and attached to releases alongside Python distributions.

• Chores

  • Updated automation tooling used for testing, documentation, packaging, performance checks, and releases.
  • Pinned cross-compilation toolchain versions for more consistent builds.
  • Updated the JSON Schema dependency to a newer compatible version.

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/publish.yml (1)

380-385: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Verify that each Linux artifact is static.

Lines 380-385 build the musl target, but the workflow only checks --help. Add a Linux-only check before packaging that fails if readelf -l reports an ELF program interpreter. This prevents publishing a dynamically linked binary when the static-binary contract changes.

Proposed verification step

+      - name: Verify Linux binary is static
+        if: ${{ matrix.zigbuild }}
+        shell: bash
+        run: |
+          set -euo pipefail
+          binary="target/${{ matrix.rust_target }}/release/switchyard-server"
+          if readelf -l "${binary}" | grep -q "Requesting program interpreter"; then
+            echo "Expected a static Linux binary: ${binary}" >&2
+            exit 1
+          fi

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/publish.yml around lines 380 - 385, Add a Linux-only
verification step after the musl `cargo` build and before packaging, targeting
the generated `switchyard-server` artifact. Run `readelf -l` and fail the
workflow when its output contains an ELF program interpreter, while allowing
static binaries without one; keep existing non-Linux packaging behavior
unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/publish.yml:
- Around line 380-385: Add a Linux-only verification step after the musl `cargo`
build and before packaging, targeting the generated `switchyard-server`
artifact. Run `readelf -l` and fail the workflow when its output contains an ELF
program interpreter, while allowing static binaries without one; keep existing
non-Linux packaging behavior unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 2e988cd6-035b-4303-a0a1-c43d722d2b28

📥 Commits

Reviewing files that changed from the base of the PR and between 2bef154 and 2790d00.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock, !Cargo.lock

📒 Files selected for processing (9)

• .github/workflows/ci.yml
• .github/workflows/commitlint.yml
• .github/workflows/docs.yml
• .github/workflows/getting-started.yml
• .github/workflows/package-portability.yml
• .github/workflows/perf.yml
• .github/workflows/publish.yml
• .github/workflows/readme.yml
• Cargo.toml

[grahamking]

Could you explain this sentence?

without having to haul in the whole Rust SDK.

There is no such thing as a dynamically linked Rust SDK. Here are the dynamic dependencies today:

$ ldd target/release/switchyard-server
        linux-vdso.so.1
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
        /lib64/ld-linux-x86-64.so.2

[ebendler]

Could you explain this sentence?

without having to haul in the whole Rust SDK.

There is no such thing as a dynamically linked Rust SDK. Here are the dynamic dependencies today:

$ ldd target/release/switchyard-server
        linux-vdso.so.1
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
        /lib64/ld-linux-x86-64.so.2

Correct. But there is no binary distribution of this product, so in order to ship a plugin that needs switchyard-server to be present, the user would have to:

install rustup -> install rust -> cargo install switchyard-server, which downloads a ton of crates and takes a few minutes to build.

Or we can post static musl binaries that run everywhere and get it with curl.