apfel is a laptop that's frequently asleep/offline; gating the release
on it (needs: [macos, linux, flatpak]) meant the whole release stalled
whenever it wasn't reachable. macos now appends its own asset directly
via the Forgejo API once it finishes, polling for the release that
linux+flatpak already created/overrode, instead of going through
actions/forgejo-release (which can only blind-create, not append to an
existing release).
Builds carrier-x86_64.flatpak from the linux job's already-built binary
rather than recompiling inside flatpak-builder's sandbox (which can't
see the shared cargo cache anyway, making an in-sandbox build pure
duplicate work). com.randogoth.carrier.release.json is a separate
manifest from the main one, which stays as-is for local
`devbox run package` dev-from-source builds.
actions/upload-artifact@v4 and download-artifact@v4 use GitHub's newer
Artifacts-v2 protocol, which Forgejo's server explicitly refuses
("not currently supported on GHES"). Forgejo maintains its own forks
(forgejo/upload-artifact@v5, forgejo/download-artifact@v7) with that
check disabled. Also drops archive: false, an input that fork doesn't
expose - the earlier binary rename already keeps filenames distinct
through the default zip/extract round-trip.
Builds macos-arm64 and linux-x86_64 release binaries in parallel and
uploads them as build artifacts; a single release job gated on both
then downloads and publishes them to one Forgejo release. Splitting it
this way avoids a real race in actions/forgejo-release itself: its
script always does a blind create-then-upload for the tag with no
merge path, so two parallel callers against the same tag either
hard-fail or stomp each other's uploaded assets.
