ci: build release binaries, and prove each one leaves its build machine

[myobie]

Nathan asked for binaries built in Actions and attached to releases. This is that, plus the checks that make an asset worth attaching.

Two platforms, two different routes, for measured reasons

Linux uses cargo, not nix. The documented cargo route already produces an ordinary portable binary — linux-vdso, libgcc_s, libc.so.6, the standard loader. Nix would produce one whose interpreter and libraries live in /nix/store.

It builds in a Debian 12 container because the glibc floor is set by the build host, not by this code: ubuntu-latest would stamp GLIBC_2.39 on the asset and lock out Ubuntu 22.04, Debian 12 and RHEL 9. Debian 12 gives GLIBC_2.34, which covers them. Zig is pinned by version and sha256.

macOS uses nix, because cargo cannot build there at all — ghostty pins Zig 0.15.2 and that Zig cannot link the macOS 26.5 SDK. But a nix-built macOS binary is not relocatable as it comes out, so the job undoes that: store dylib references are rewritten to their /usr/lib counterparts, any store LC_RPATH is deleted, and the binary is re-signed because install_name_tool invalidates the signature and Apple silicon will not run a mis-signed one.

Measured in the job, on the same store hash seen on a real machine:

before:  /nix/store/0ky902fx…-libiconv-115.100.1/lib/libiconv.2.dylib
after:   /usr/lib/libiconv.2.dylib
         no /nix/store references remain
         dist/pty: satisfies its Designated Requirement

Every asset is gated, not trusted

• fails if the binary references /nix/store;
• fails if --version reports unknown;
• runs the binary before staging it;
• publishes a sha256 beside each asset.

Two defects this caught in its own output, which is why the gates are there

0.13.0-rust+unknown. The first Linux asset could not say which commit it was. build.rs derives the sha by running git, and git refused inside the container over directory ownership; the macOS job got the real sha because it has no container. That is not cosmetic — it is the exact failure this work exists to fix, since a binary served a machine for five days and its version string was the only way to find out which build it was. Fixed with PTY_BUILD_SHA, and now gated.

Bad substitution. The fix for that was itself platform-dependent: ${GITHUB_SHA::7} is a bashism, the container runs sh, and the macOS runner accepted it. Same asymmetry one layer up. Now cut, verified in dash and bash side by side.

Both times the fix went into both jobs rather than the one that failed, because a job passing by luck of its environment is how the next failure looks like a new bug.

Verified by download, not by job summary

Both assets pulled and checked locally: checksums match, both report 0.13.0-rust+01af50e, the Linux one runs at GLIBC_2.34 with only libgcc_s and libc, and the macOS one contains zero /nix/store strings.

How a release is cut

Push a v* tag. A workflow_dispatch run builds and verifies both assets without publishing, so an asset can be proved before anything is public.

The temporary branch trigger that let this run before merging is removed.