[PAMulligan]

Closes #189. Part of #186.

Problem

gui-release.yml was triggered by release: published, but release-please publishes the Release with GITHUB_TOKEN, and GitHub never starts a workflow for an event that token created. The workflow had zero runs; v2.1.2, v2.1.3 and v2.1.4 shipped without installers.

A first version of this PR (Aurelius's publish-then-attach shape) built and packaged on all three platforms in about 90 seconds each, then every upload failed with HTTP 422: Cannot upload assets to an immutable release: this repository has GitHub's immutable releases enabled (Aurelius does not). Nothing can be attached after publication, and no already-published release, v2.1.4 included, can be back-filled.

Fix: draft first

• release-please-config.json: "draft": true and "force-tag-creation": true. release-please creates the tag immediately and the Release as a draft (without the eager tag, GitHub would create it only on publish, which release-please's docs say breaks its lookup of the previous release).
• release-please.yml exposes release_created and tag_name and calls gui-release.yml in the same run with the tag, secrets: inherit.
• gui-release.yml is a reusable workflow with three jobs: check refuses a tag whose release is not a draft (published releases are immutable here); build checks out the tagged commit, builds both macOS DMGs, the NSIS EXE and the AppImage, smoke-tests each, keeps them as workflow artifacts and attaches them to the draft with --clobber; publish runs only when every platform succeeded and flips the draft to published, listing the assets in the job summary. workflow_dispatch with a tag reruns the attach-and-publish for a draft that an earlier run left unpublished; without a tag it is a dry run that keeps the installers as artifacts. The release: published trigger is gone, since it could only ever fail on this repository.
• docs/GUI.md and docs/RELEASING.md describe the chain and the recovery path.

Verification

• All three files parse; the release-please schema accepts both options.
• Dispatch from this branch with tag=v2.1.4 (a published release): the check job must fail with the "already published" message and skip the build.
• Dispatch from this branch with no tag: a dry run on the three runners, installers kept as artifacts, nothing published.
• The real draft-attach-publish path can only be exercised by the next release-please run after this merges: the next Release PR merge should produce a published Release carrying Flavian-<version>.AppImage, Flavian Setup <version>.exe and the two DMGs.

🤖 Generated with Claude Code

[PAMulligan]

Result of the manual dispatch against v2.1.4 (run 42518497713): all three platforms installed, built, passed the smoke test and packaged the installers in about 90 seconds each (macOS produced both DMGs). The only failing step was the upload: HTTP 422: Cannot upload assets to an immutable release. This repository has GitHub's immutable releases enabled, which Aurelius does not, so the Aurelius-style chain (publish, then attach) cannot work here, and no release that release-please has already published can be back-filled, v2.1.4 included. I am reworking the chain on this branch to the shape immutable releases allow: create the release as a draft, build and attach the installers, then publish. Converting to draft until that is pushed.