Fix Linux notification clicks not focusing BB, and publish macOS 13 update requirement

[salemsayed]

Human comments

What was wrong

Replaces #3692, which the stale-PR automation closed without a review. This branch is rebased onto b23150d88 and re-verified from scratch.

On Linux Wayland, clicking a BB desktop notification opens the right thread but leaves BB minimized or behind other windows. There are two causes, and both are still present on current main:

1. The AppImage bundles an old libnotify.so.4 in usr/lib. It shadows the system library and has no activation-token API (notify_notification_get_activation_token). Electron 44 can only forward the compositor's xdg-activation token when that API exists, so GNOME and KWin refuse the focus request. The running 0.43.5 nightly maps /tmp/.mount_bb_*/usr/lib/libnotify.so.4.0.0, not the system 0.8.8.
2. The click handler in plugins/push-notifications/client.ts only calls renderer window.focus(). That can't un-minimize or raise a Wayland toplevel.

Separately, generate-version-feed.mts still publishes minimumSystemVersion: null even though electron-builder.config.json requires macOS 13.0.0. The updater therefore can't keep macOS 12 users off releases that won't launch for them.

What changed

• patches/app-builder-lib@26.15.7.patch: AppImage staging renames the bundled libnotify.so.4 to unversioned libnotify.so. Electron tries the system's versioned library first and falls back to the bundled copy. smoke-linux-appimage-lifecycle.mjs asserts this layout.
• desktop-window-focus.ts, main.ts, preload.ts, desktop-window-command-ipc.ts, desktop-contract/info.ts: new payload-free focusWindow() preload method and IPC. Only a registered application webContents may call it, and it restores, shows and focuses that sender's own window.
• push-notifications/client.ts: on Linux desktop, a notification click also calls bbDesktop.focusWindow() when available. window.focus() and routing are unchanged. Older shells without the method keep the previous behavior. Web and macOS are unchanged.
• generate-version-feed.mts: macOS JSON and YAML feeds publish minimumSystemVersion: 22.0.0 (Darwin for macOS 13) and keep the other YAML metadata.
• apps/desktop/package.json: test installs Electron's lazy runtime first, so parallel desktop tests don't race to download it.

No server/daemon wire change and no HOST_DAEMON_PROTOCOL_VERSION bump.

How you verified

Before/after on real desktops. AppImages were built from upstream main b23150d88 and from this branch. Each was run in a fresh Ubuntu 26.04 QEMU/KVM guest on native Wayland: GNOME Shell 50.1 and KDE Plasma/KWin 6.6.6, both with system libnotify 0.8.8. Each case launched BB fresh against an isolated server built from the same commit, then either minimized BB or covered it with another app's window. A real Codex turn on "Notification target" produced the notification, and the QEMU pointer clicked it. Focus was checked in Electron, in the renderer (document.hasFocus()), and in the compositor (the focused window's PID from a GNOME Shell extension or KWin script).

Case	GNOME 50.1	KDE Plasma 6.6.6
main, BB minimized	Opens thread, stays minimized	Opens thread, stays minimized
main, BB behind another window	Opens thread, stays behind	Opens thread, stays behind
This PR, BB minimized	Restored, focused, on thread	Restored, focused, on thread
This PR, BB behind another window	Raised, focused, on thread	Raised, focused, on thread
Control: system libnotify, no native focus request	Stays minimized	Stays minimized
Control: native focus request, legacy libnotify forced via LD_PRELOAD	Focus refused; Shell posts "“Notification target” is ready"	Focus refused; task marked as demanding attention

The two controls show that both halves of the fix are needed. Process maps confirm which libnotify each run loaded: main loads the AppImage's libnotify.so.4.0.0, and this PR loads /usr/lib/x86_64-linux-gnu/libnotify.so.4.0.0.

GNOME, BB minimized (left: main, right: this PR)

KDE, BB minimized (left: main, right: this PR)

GNOME and KDE, BB behind another window

Stills: notification shown and result after click

MP4s, the per-case summary and the method are in this gist.

Tests (Node 22.19.0 per .nvmrc): pnpm exec turbo run test typecheck --filter=@bb/desktop --filter=bb-plugin-push-notifications --filter=@bb/desktop-contract passes 12/12 tasks: desktop 454 passed with 1 existing skip, push notifications 24, desktop contract 22. Under Node 26, client.test.ts fails on main too (localStorage is undefined), so that failure is not from this change. turbo run desktop:build:linux --filter=@bb/desktop passes, and the extracted AppImage contains usr/lib/libnotify.so -> libnotify.so.4.0.0 with no libnotify.so.4. The feed change is covered by desktop-version-feed.test.ts.

Not tested: signed macOS GUI notifications and updater install on macOS 12, standalone Xorg, and other Linux distributions. On Wayland, focus still needs compositor xdg-activation support and a system libnotify of 0.7.10 or later. Without one, BB falls back to the bundled library: notifications still open the thread, but BB can't take focus.

AGENT GENERATED

🤖 Generated with Claude Code