ci(release-plz): fail loudly when a release silently stalls

[AprilNEA]

Closes the loop on the release-plz governance (follow-up to #9 + the v0.1.3 manual release).

Context

The path-dep history trap is healed: the manual v0.1.3 release moved the crates.io baseline to a clean git-dep commit (6e78257), and the release-plz run right after it ran release-pr cleanly (no cargo package error, no 422, {"prs":[]}). The stale-branch 422 is auto-pruned (#9). So release-plz works again.

The remaining gap (flagged by the reviewer on #9): release-plz/action swallows a release-pr HTTP 422 as a warning and reports no PR, so a future glitch would stall releases silently — indistinguishable from a quiet week. That's exactly how releases quietly stopped before v0.1.3.

Fix

A guard step that runs only when prs_created == 'false':

• skips if a release-plz-* PR is already open (the normal "updated, not created" path);
• otherwise, if there are release-worthy commits (feat/fix/perf/breaking !) since the last v* tag, it ::error::s and fails the job.

So a swallowed failure surfaces, while genuine no-ops (only chore/ci/docs, or nothing since the tag) pass. If release-pr hard-errors (e.g. the old path-dep case), the step already exits 1 — loud — and this guard is skipped.

Verification note

On merge, release-plz runs with prs_created=false (nothing to release since v0.1.3) — the guard finds no release-worthy commits since v0.1.3 (the merge is a ci: commit), so it passes. No false positive.

[pullfrog]

ℹ️ Guard logic is sound — one scope observation worth a look.

Reviewed changes — initial review of the release-plz stall guard plus the bundled macOS tray refactor and action version bumps.

• Add Guard against a silently stalled release step in release-plz.yml — runs only when release_pr.outputs.prs_created == 'false', short-circuits on an already-open release-plz-* PR, then ::error::s when git log <last v* tag>..HEAD contains feat|fix|perf or any breaking <type>!: commit.
• Bump actions/checkout v4→v6 and actions/create-github-app-token v2→v3 in both jobs of the same workflow (not mentioned in the PR description).
• Extract platform/tray.rs inline Cocoa FFI into a new platform/status_item.rs module — typed wrappers (StatusItem, Menu, MenuItem, ActionTarget, ActivationPolicy) each 1:1 around the previous msg_send! blocks; storage in OnceLock narrows from raw usize to the wrapper structs while preserving the existing Sync-via-usize convention.

ℹ️ Three independent changes bundled under a CI-only title

The PR title and description scope this to the release-plz stall guard, but the branch also carries an unrelated macOS FFI refactor (1dfa2c2) and two actions/* major-version bumps (checkout v4→v6, create-github-app-token v2→v3) that aren't mentioned anywhere.

Each piece is fine on its own — the refactor is behavior-preserving, the bumps are plausible — but they have separate revert surfaces and separate review concerns from the guard logic.

Technical details

# Three independent changes bundled under a CI-only title

## Affected sites
- `crates/openlogi-gui/src/platform/{mod,status_item,tray}.rs` — macOS Cocoa FFI extraction; reviewable on its own, unrelated to release CI.
- `.github/workflows/release-plz.yml:25` and `:135` — `actions/checkout@v4 → v6`.
- `.github/workflows/release-plz.yml:65` and `:172` — `actions/create-github-app-token@v2 → v3`.

## Required outcome
- Either split the macOS refactor + the action bumps into their own PRs, or extend the PR title/body to acknowledge them so a future bisect / revert reader knows what they're actually reverting.

## Open questions for the human (optional)
- Are the action bumps deliberate (vetted v6 / v3 release notes) or incidental? They're not in the PR description, so flagging in case they rode in via an editor / agent autocomplete rather than an intentional bump.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}