Release binaries: avoid an assetless "latest" release while the archives build #372

Follow-up from the automated review of #369 (prebuilt release binaries, #366), item 3.

Problem

release-binaries.yml runs on release: published. From the moment a release is published until publish.sh uploads SHA256SUMS, that release is GitHub's "latest" and has no archives. The gap covers the uncached static builds of three targets plus the fresh-host checks: tens of minutes on every release, not only a misnamed tag.

During that window, the README one-liner (install-release.sh with no tag follows /releases/latest) refuses with "the latest release, X, has no prebuilt archive". The refusal is clear, but every user in that window gets it.

Options

1. Publish with "Set as the latest release" unticked, and have the workflow mark it latest once complete.
   • make_latest: false in the API, gh release create --latest=false in the CLI.
   • After publish.sh uploads SHA256SUMS and the post-upload check passes, run gh release edit <tag> --latest.
   • The release-manager docs ("Cutting a release" in README and AGENTS.md) would say to untick "latest" when publishing.
2. Draft first. Upload assets to a draft release, then publish it.
   • This needs a different trigger: release: published doesn't fire for drafts, so the workflow would run on workflow_dispatch or on a tag push.
3. Make the installer fall back. When /latest has no archive for the platform, it uses the newest release that has one. That's more logic in the installer, and it hides a broken release.

Option 1 looks smallest. It needs:

• a make_latest step in the publish job, after the existing post-upload verification;
• a self-test case against the fake gh: it must flip only after SHA256SUMS is up, and never on a refusal.

Deferred from #369 to keep that PR to packaging and publishing the assets.