#67 ci: publish GhosttyNextKit from release/* branches too

Summary

• The GhosttyNextKit workflow published only from main. A push to a release/** branch (or a dispatch with publish on one) now publishes too.
• Why: cmux pins ghostty-next at 9ce9b7d08. main now also has the v1.4.0 / Zig 0.17 merge, which cmux does not pin yet. A P0 fix (cmux E2, a stale wrap_continuation after a scroll region scroll, #66) must not wait for that bump. With this change, release/cmux-9ce9b7d0-e2 = the pin plus only the fix publishes its own xcframework-<sha>-apple-v6.
• The release rules do not change (next/release_plan.py: publish only when a build input changed since the newest ancestor release; a tag is never reused).
• A release/* release is created with --latest=false, so it never becomes the repository's latest release.

Testing

• The YAML parses. The plan job runs next/test_release_plan.py on this PR.
• The first real use is release/cmux-9ce9b7d0-e2. That branch carries this commit, because GitHub reads the workflow from the pushed commit.

Changelog

none

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Publishes GhosttyNextKit releases from release/* branches in addition to main, so an embedder pinned to an older ghostty-next commit (cmux at 9ce9b7d08) can ship a fix without pulling in unrelated main changes like the v1.4.0 / Zig 0.17 merge.

• The publish rules and tag-reuse guard are unchanged.
• release/* releases are created with --latest=false, so they never become the repository's latest release.
• The workflow reads from the pushed commit, so the first release/* branch — release/cmux-9ce9b7d0-e2 — carries this change itself.