fix(release): stop shipping the wrong binaries, and delete the dead notifier

Works #11 — the release half. Three defects, none of them the Apple signing gate, which stays exactly as it is.

craft-linux-x64.zip ships Windows binaries

Not a hypothesis — this is what the last successful release actually published. gh release download v0.0.37:

The Linux leg cross-compiles x86_64-windows into zig-out/bin/, copies one file out to zig-out/cross/windows-x64/, then rebuilds native — and nothing removes the rest. The pantry action's packager zips zig-out/bin whole and unfiltered, so everything the cross build left behind goes out under the Linux archive name, PDB included.

Reproduced with the pinned CI compiler, running the workflow's own commands:

--- zig-out/bin after cross-compile:
craft.exe
--- zig-out/bin after 'restore native' (this is what gets zipped):
craft
craft.exe

Cleared before the restore build on both legs. The macOS leg is not currently affected — its x86_64-macos cross reuses the same filename and is overwritten — but it is one added target away from the same bug, so it gets the same line.

craft-demo ships in the native-leg archives

build.zig called b.installArtifact on the demo, so it landed in zig-out/bin on every build — visible above in both craft-linux-x64.zip and craft-darwin-arm64.zip. The signing and notarization loops name only craft:

for binary in \
  packages/zig/zig-out/bin/craft \
  packages/zig/zig-out/cross/darwin-x64/craft; do

so once a release does sign successfully, craft-darwin-arm64.zip will carry a notarized craft beside an unsigned craft-demo. (In v0.0.37 both are merely ad-hoc signed — that release predates these steps — so today the defect is the stray binary, and the signing mismatch is what it becomes.)

The demo is no longer installed. zig build run-demo still builds and launches it — verified — it just doesn't end up in the install prefix.

The notify job never notified

- uses: ./.github/actions/discord-notify
  if: hashFiles('.github/actions/discord-notify/action.yml') != ''

git rev-list --all --objects | grep -c discord-notify → 0. That path exists in zero objects across every branch, tag and commit in the repository's history. The guard skipped the only real step, so the job checked out the repo, did nothing, and reported success — across runs from May to August, including 31969941167, where the Apple gate failed, Publish & Release was skipped, no release happened, and discord-notification still went green.

Deleted, and the notification handed to the pantry action, which declares discord-webhook and notification-title as first-class inputs. DISCORD_WEBHOOK_URL is not set at repo, organization or environment scope, so nothing is sent either way today — but the plumbing is now real rather than a no-op job burning a runner.

Verified

• published v0.0.37 assets unzipped and listed (above) — the defect is in shipped artifacts, not just in theory
• zig build -Doptimize=ReleaseSafe → zig-out/bin now contains exactly craft
• zig build run-demo still builds and launches the demo
• zig build test green, zig fmt --check build.zig clean
• release.yml parses; pantry and npm are the remaining jobs and the publish step's inputs resolve

Still open on #11, and needing your call

npm is needs: [pantry], but a surviving matrix leg publishes anyway. With the Apple gate failing the darwin leg, npm is skipped — while the Linux leg's own Publish & Release still runs. Each leg contributes only its own binaries to a shared release; that was confirmed from v0.0.37's asset upload timestamps lining up with each leg's completion. So the outcome is a GitHub release and a registry publish with partial binaries and zero npm packages — which is why npm latest for craft-native is still 0.0.55 from 2026-07-30 while tags v0.0.56–v0.0.67 all exist.

The fix is to make publishing atomic: both legs upload binaries as artifacts, one downstream publish job that needs: [pantry] releases once. That restructures a tag-only, outward-publishing workflow I cannot exercise from here, so I have not landed it blind. Say the word.

Separately, the v0.0.67 run has been queued ~10 hours (since 04:24:01Z, run_attempt 1, updated_at never advancing past created_at) with zero steps executed. Every non-GitHub explanation was eliminated: macos-15 got a runner in 3s for another run today, the queue holds nothing else, there are no pending deployments or approvals, Actions is enabled and unrestricted, and the tag peels to the run's head_sha. Note that gh run cancel && gh run rerun chained will not work — re-run requires a completed run, so it needs a wait between the two calls, and an orphaned queued run may ignore cancel entirely and want GitHub Support with the run ID.