chore(master): release 0.23.0

[arcbox-labs]

🤖 I have created a release beep boop

0.23.0 (2026-08-08)

Features

• config: generate branded desktop and mobile identity (#428) (a50ea0f)

---

This PR was generated with Release Please. See documentation.

[pullfrog]

✅ No new issues found.

Reviewed changes — the full generated release-please diff for the 0.23.0 desktop release, checked against the actual commit range since v0.22.0 and against the release contracts in docs/RELEASE.md.

• Manifest bump — .release-please-manifest.json "." moves 0.22.0 → 0.23.0.
• Desktop version bump — apps/desktop/package.json version → 0.23.0, written through the config's extra-files jsonpath $.version.
• Changelog entry — a new ## [0.23.0] section listing feat(config): generate branded desktop and mobile identity (#428, a50ea0f).

Three things I checked rather than assumed:

• The range since v0.22.0 (6d8f9dac) is exactly two commits — #427 (test:) and #428 (feat:). test: has no default changelog section, so its omission is correct, and a minor bump is right for a feat under bump-minor-pre-major on 0.x.
• Invariant 5 holds: apps/desktop/package.json reads 0.23.0 and the tag will be v0.23.0, which is what build-desktop.yml's "Assert package version matches release tag" step compares.
• #428's brand work does not re-brand this release. assertStagedConfigMatchesGenerated marks a build branded only when the config bundle's brandId !== 'linkcode', so the default release keeps electron-builder.yml's appId: com.arcboxlabs.linkcode.desktop, productName: LinkCode, and the base publish feed — artifact names and updater feed continuity for 0.22.0 clients are unaffected.

ℹ️ This is the first tag cut since the desktop packaging path was reworked

Nothing in this diff is wrong, but v0.23.0 is the first release to run #428's reworked packaging scripts for real. Signed builds set LINKCODE_REQUIRE_CONFIG_BUNDLE=1, so the new hard-fail assertStagedConfigMatchesGenerated gate executes on a real signed release for the first time on this tag; today it has unit coverage only. A failure there aborts packaging after the tag already exists, which is the awkward state to unwind.

Technical details

# First signed build on the reworked desktop packaging path

## Affected sites
- `apps/desktop/scripts/package-config.mts` — `assertStagedConfigMatchesGenerated` is a new hard-fail gate comparing `apps/desktop/generated` against `apps/desktop/out/config`; it throws rather than degrading.
- `apps/desktop/scripts/package-app.mts` — calls that gate before every pack, and additionally refuses `-c.appId` / `-c.productName` / `-c.protocols` passthrough overrides on branded builds.
- `.github/workflows/build-desktop.yml` — sets `LINKCODE_REQUIRE_CONFIG_BUNDLE: 1` whenever `sign` is true, so the config-bundle staging path is mandatory on exactly this release.

## Required outcome
- Confidence that a signed desktop package succeeds end-to-end on `a259c3f` before the `v0.23.0` tag is pushed.

## Suggested approach
- Dispatch `release-desktop.yml` with `dry_run: true` against this branch or the prospective merge SHA — it builds and signs but publishes nothing, which is precisely the rehearsal this situation calls for.

## Open questions for the human
- Does the configured `CONFIG_RELEASE_MANIFEST_DESKTOP` for this release resolve to `brandId: linkcode`? That is the value that keeps `branded` false and preserves `appId` / `productName` / the publish feed; it is an org-level repo variable and not verifiable from the repo.

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

[lucas77778]

Reviewed the complete release-please diff and release contracts. Verified the manifest and desktop package both advance from 0.22.0 to 0.23.0, the changelog accurately reflects the feat commit since v0.22.0 while correctly omitting the test-only commit, and the minor bump matches bump-minor-pre-major. The tag/package version contract remains aligned, and all current CI and CodeQL checks pass. No blocking findings.