chore(master): release 0.24.0

[arcbox-labs]

🤖 I have created a release beep boop

0.24.0 (2026-08-17)

Features

• providers: add StepFun API support (#456) (c4a2e49)

Bug Fixes

• prevent daemon fsync crash and Pi catalog failures (#454) (964f04c)

---

This PR was generated with Release Please. See documentation.

[pullfrog]

✅ No new issues found.

Reviewed changes — the full release-please diff cutting desktop 0.23.2, checked for version agreement across the release train and for changelog completeness against master.

• .release-please-manifest.json — "." bumped 0.23.1 → 0.23.2, the train's source of truth.
• apps/desktop/package.json — version bumped to 0.23.2, written via the extra-files $.version jsonpath in release-please-config.json.
• apps/desktop/CHANGELOG.md — new ## [0.23.2] section with a single Bug Fixes entry for #454.

All three agree on 0.23.2, and the patch bump is correct — the only changelog-visible commit since v0.23.1 is 964f04c fix: prevent daemon fsync crash and Pi catalog failures (#454). I also confirmed there is no version drift elsewhere: no 0.23.1 references survive outside the changelogs, root package.json stays 0.0.0, and apps/mobile/app.json keeps its own expo.version because exclude-paths deliberately drops apps/mobile and apps/webview. The version/tag gate at build-desktop.yml:227-235 is satisfied for tag v0.23.2.

ℹ️ This release will be the first signed build to run actions/setup-node v7

Nothing to change in this PR — flagging it only because a release PR is the point where CI drift becomes a shipping risk. Master gained 6ad38cd5 chore(ci): bump the actions-all group … (#439) after this PR's base, which bumps actions/setup-node from v6 to v7.0.0 (a major) in build-desktop.yml and in five jobs of release-brand-matrix.yml — the signed-release path. Since finalize-releases.yml tags the post-merge master HEAD, that bump rides along into v0.23.2 without appearing anywhere in the changelog (correctly, since chore is hidden).

Technical details

# Signed 0.23.2 build is the first to exercise `actions/setup-node@v7`

## Affected sites
- `.github/workflows/build-desktop.yml:168` — `actions/setup-node` v6 → v7.0.0, used by the `sign: true` build.
- `.github/workflows/release-brand-matrix.yml:146,377,522,669,826` — same major bump across five release jobs.
- Neither file is touched by this PR; both arrive via `6ad38cd5`, which sits on master ahead of this PR's base `964f04cf`.

## Why it lands in this release
`finalize-releases.yml` binds release-please to the CI-tested master SHA and creates the tag there, so
the `v0.23.2` ref includes `6ad38cd5`. `release-desktop.yml` triggers on `v*.*.*` and calls
`build-desktop.yml` with `sign: true`.

## Required outcome
- Confidence that the signed macOS/Windows build still succeeds under setup-node v7 before the
  published artifact is the thing that discovers otherwise.

## Suggested approach (optional)
- Dispatch `release-desktop.yml` via `workflow_dispatch` with `dry_run: true` (the default) against
  master. It builds and signs but publishes nothing, which is exactly the smoke test this needs.

## Open questions for the human (optional)
- Was setup-node v7 already exercised on a signing runner via some other workflow run? If so this is
  a non-issue and needs no dry run.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — this PR was recut since my last review: release-please force-replaced the branch, so 2716f8ee cutting 0.23.2 (patch) became 49628286 cutting 0.24.0 (minor). I re-verified the whole three-file cut rather than a delta, because the prior head was never fetched into this shallow checkout and the incremental range-diff could not be computed.

• Bump promoted patch → minor — c4a2e496 feat(providers): add StepFun API support (#456) landed on master after the first cut, and bump-minor-pre-major: true (release-please-config.json:14) makes a pre-1.0 feat: a minor. 0.24.0 is the right number.
• All three files agree on 0.24.0 — .release-please-manifest.json (".", the train's source of truth), apps/desktop/package.json version (written via the extra-files $.version jsonpath), and the new apps/desktop/CHANGELOG.md section.
• Changelog now carries both entries — Features for #456 and the Bug Fixes entry for #454 that the abandoned 0.23.2 cut would have shipped alone.

The abandoned cut left no residue: zero occurrences of 0.23.2 anywhere in the repo, and the compare link correctly rebased to v0.23.1...v0.24.0 — release-please's own evidence that no v0.23.2 tag was ever created. No 0.23.1 references survive outside the changelogs; root package.json stays 0.0.0 and apps/mobile/app.json keeps its own expo.version per exclude-paths. Changelog completeness holds too — git log origin/master --not HEAD^ is empty, so this PR's base is master HEAD and nothing rides in beyond the two documented commits plus three correctly-hidden chore riders. The version/tag gate in build-desktop.yml is satisfied for tag v0.24.0.

Two things I checked because a minor bump ships real behavior. Invariant 1 is not engaged: c4a2e496 touches only the provider catalog, two i18n locales, service-icon.tsx, and two test files, so WIRE_PROTOCOL_VERSION correctly stays at 77. And #456's own review finding was fixed before merge — it imports ~icons/lobe-icons/stepfun-color rather than a hand-rolled glyph, leaving SERVICE_GLYPHS' narrow type intact.

One note rather than a new finding: the actions/setup-node v7 concern from my first review is unchanged and still open — 0.24.0 is still the first signed build to run it, and the release-desktop.yml dry_run: true dispatch is still the cheap smoke test. The two dep-bump riders that arrived since (@pierre/trees beta.6, @better-auth/expo rc.2) carry no release risk; installs come from the committed lockfile.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[arcbox-labs]

🤖 Created releases:

• v0.24.0

🌻