[Build] Publish release before Homebrew update

[samzong]

Summary

Publish GitHub Releases before dispatching the Homebrew tap update so the tap workflow can resolve public release assets.

Type of change

• [Feat] new feature
• [Fix] bug fix
• [UI] UI or UX change
• [Docs] documentation-only change
• [Refactor] internal cleanup
• [Build] CI, packaging, or tooling change
• [Chore] maintenance

Why is this needed?

The stable release flow dispatched update-homebrew.yml while electron-builder's GitHub Release was still a draft. The tap update then could not see the public release or macOS DMG assets.

What changed?

• Publish the GitHub Release after release notes are generated and before Homebrew dispatch.
• Gate the Homebrew dispatch on isDraft=false.
• Quote macOS signing paths so actionlint/shellcheck passes cleanly.

Architecture impact

• Owning layer: build/release workflow
• Cross-layer impact: none
• Invariants touched from docs/architecture-invariants.md: none
• Why those invariants remain protected: this only changes GitHub Actions release ordering and shell quoting.

Linked issues

None.

Validation

• pnpm lint
• pnpm test
• pnpm build
• pnpm check:ui-contract
• Manual smoke test
• Not run

Commands, screenshots, or notes:

pnpm exec prettier --check .github/workflows/release.yml
actionlint .github/workflows/release.yml
git diff HEAD~1..HEAD --check

Screenshots or recordings

Not UI-facing.

If the change touches renderer styles, layout, spacing, component states, or interaction polish, explain which tokens, variables, states, or pnpm check:ui-contract rules were intentionally preserved or changed.

Not applicable.

Release note

• No user-facing change. Release note is NONE.
• User-facing change. Release note is included below.

NONE

Checklist

• All commits are signed off (git commit -s)
• The PR title uses at least one approved prefix: [Feat], [Fix], [UI], [Docs], [Refactor], [Build], or [Chore]
• The summary explains both what changed and why
• Validation reflects the commands actually run for this PR
• Architecture impact is described and references any touched invariants
• Cross-layer changes are explicitly justified
• The release note block is accurate

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[github-actions]

Hi @samzong,
Thanks for your pull request!
If the PR is ready, use the /auto-cc command to assign Reviewer to Review.
We will review it shortly.

Details

Instructions for interacting with me using comments are available here.
If you have questions or suggestions related to my behavior, please file an issue against the gh-ci-bot repository.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c22741454d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid triggering Homebrew tap update twice

For stable tag runs, publishing the Release here also fires .github/workflows/update-homebrew.yml because that workflow is configured with on: release: types: [published], and this same release workflow still later dispatches update-homebrew.yml manually. That creates two tap-update runs for the same tag; if they both checkout the tap before either pushes, one push can be rejected as non-fast-forward or report a duplicate failed release-side workflow even though the assets are valid.

Useful? React with 👍 / 👎.