Fix notification activation and macOS updates after Electron 44 upgrade

[salemsayed]

Human comments

What was wrong

Electron 44.3.0 and SQLite 13 are already merged in #3659. This PR fixes the remaining AppImage notification and macOS updater gaps. The AppImage still bundles an old libnotify that shadows the system library and loses Wayland activation-token support; BB's click handler still relies on renderer window.focus() without a native restore/show/focus request; and the custom macOS update feed still publishes no minimum system version despite the app now requiring macOS 13. Our branch already includes #3659 and makes no further Electron or SQLite upgrade.

What changed

Gap remaining after #3659	This PR adds
Electron 44 supports Wayland activation tokens, but the AppImage's bundled old libnotify prevents using the system library's support.	Prefer system versioned libnotify while retaining the bundled unversioned fallback.
Clicking a notification can navigate while leaving BB minimized or unfocused.	An additive Linux native request that restores, shows and focuses only the notification's owning window.
The macOS app requires version 13, but the custom JSON feed has minimumSystemVersion: null.	Publish the equivalent Darwin 22.0.0 requirement in JSON and YAML update feeds for updater compatibility checks.

• Keep window.focus() and add a Linux-only native request. Payload-free IPC checks the live application-webContents registry and restores/shows/focuses only the sender's window. The optional preload contract retains old-shell compatibility; routing is unchanged.
• Patch app-builder-lib's AppImage staging to expose legacy libnotify as unversioned libnotify.so. Electron first tries system versioned libraries, then this fallback. The lifecycle smoke checks that packaging neither shadows versioned libraries nor drops the fallback.
• Publish Darwin 22.0.0 in JSON and YAML macOS update feeds, matching Upgrade Electron to 44.3.0 with compatible bundled SQLite #3659's macOS 13 minimum while preserving other YAML metadata.
• Install Electron's lazy development runtime before parallel desktop tests to avoid competing downloads.

No server/daemon wire change, protocol bump or additional SQLite upgrade.

How you verified

The runtime upgrade alone did not resolve the observed failure: an earlier Electron 44 diagnostic run with the native BB request restored the GNOME window and opened the thread, but Electron, renderer and compositor captures still showed it unfocused while the legacy library was bundled. Using the system library made that click focus correctly. The final packaged results below verify the combined fixes. The earlier renderer-only control on Electron 42 also left the target minimized and unfocused, demonstrating why the BB native request is needed alongside runtime token support.

Application commit 02057cdfe6538dde34456ef82bb20a2ad99abdd6, rebased on 96fddad26. Final AppImage SHA256: 8a5ed4d636e3c19244e1e685dc740fe652e06a786350c92a2581519f407798da.

• CI passes: build/typecheck/lint, server, app, integration, packages, Linux/macOS bb-app package smoke and PR gates. Mobile E2E and Node compatibility jobs were skipped. The Mac smoke runs the Node package, not signed Electron notifications.
• Local Turbo: 58/58 tasks; 440 tests passed and one existing skip (desktop 334, notifications 25, launcher 81), with typechecks and AppImage packaging. Includes native SQLite regression and packaged SQLite/offline npm smoke. Frozen install and git diff --check pass.
• Final AppImage, Ubuntu 26.04 QEMU/KVM native Wayland: GNOME 50.1 and KDE Plasma/KWin 6.6.6 each pass background-window and minimized notification clicks, correct thread, restored focus, reload and thread-read state. 4/4 tested scenarios. Both old 41.7 minimized controls restored/navigated but failed focus.
• Original Omarchy host: correct BB instance, hidden restoration and cross-workspace activation, 3/3 scenarios. A local frameless guard misread flattened process arguments; its lock was held temporarily to stop it closing test windows. BB kept its normal desktop identity. No installed app or desktop configuration changed.
• Actual agent completions generated notifications; pointer input clicked them. The real callback/preload/useBbNavigate path ran. Electron, renderer and compositor focus were independently captured; screenshots inspected. Process maps confirm system libnotify. GNOME also passes the source-controlled AppImage lifecycle smoke, including owned-server survival after GUI mount removal.

Before rebasing, the equivalent package also passed KDE XWayland, owned runtime startup in both VMs, and legacy-fallback delivery/restoration/navigation with the system library unavailable. Those additional cases were not repeated on the final artifact. The existing desktopName warning remains; VM fixtures include a BB desktop entry, so default association on every distribution is not established.

Costs and compatibility

The macOS cutoff and SQLite runtime requirements below were introduced by #3659. This PR adds the matching update-feed requirement; its Linux-specific maintenance cost is the packager patch and system-library dependency for Wayland focus.

• macOS 12 is dropped by Electron 44 / Upgrade Electron to 44.3.0 with compatible bundled SQLite #3659. Users must upgrade the OS or retain an older release; this PR adds updater protection. BB already ships arm64-only, and Apple lists the original M1 Macs as Ventura-compatible.
• macOS notifications require signing from Electron 42 onward. A signed Mac smoke remains outstanding.
• Older Linux: Upgrade Electron to 44.3.0 with compatible bundled SQLite #3659's SQLite x64 prebuild requires glibc 2.34+ and GLIBCXX_3.4.29. Older systems need compatible native builds.
• Download/memory cost: the integrated AppImage grows 178.23 → 191.23 MB (+13.00 MB / 7.3%); that includes BB/SQLite changes, not just Electron. Measured private memory grows 2.8%.
• Wayland: activation needs compositor support and libnotify token support (0.7.10+). The bundled fallback delivers notifications and opens threads but cannot reliably activate a window. The pinned packager patch remains maintenance work.
• Web/mac retain the renderer focus attempt; mobile WebViews remain excluded and do not embed Electron. Physical macOS/mobile and standalone Xorg remain untested.

Background: Electron upgrade benefits and benchmarks, already delivered by #3659

These measurements compare Electron 41.7 with 44.3 using identical BB code and data. They are benefits of the runtime upgrade already merged in #3659, not performance gains produced by this PR's notification or updater changes. They remain here as supporting background for the runtime choice.

Measured with identical BB code and data, changing only Electron 41.7.0 to 44.3.0:

Measurement	41.7	44.3	Change
GUI startup, fresh profile / existing server	2,611 ms	2,373 ms	9.1% less time
GUI startup, warm profile / existing server	2,378 ms	2,043 ms	14.1% less time
Repeated thread switching, warm profile	197 ms	154 ms	21.9% less time
Speedometer 3.1	13.73	19.01	38.5% higher score
Desktop private memory, backend excluded	407.6 MiB	419.1 MiB	11.5 MiB / 2.8% more

Full report, exact harness, raw samples and uncertainty intervals. Linux i5-11400 / UHD 730, native Wayland, same application archive/server, 3 projects / 120 threads / 20,345 events. Six paired launches per profile condition and version, alternating order; three full Speedometer runs per version, ten iterations each. One pair was repeated because a window lost focus, with original samples retained. Steady CPU was effectively unchanged. These are local GUI/engine measurements, not Mac, FUSE-mount, backend-startup or model-inference benchmarks.

There are specific upstream mechanisms behind the performance case: startup snapshots and cached preload bytecode without blocking startup IPC, plus ThinLTO. Electron's separate Linux experiment measured app.ready at 197.8 → 148.7 ms with snapshots (24 samples/build), and Speedometer at 22.08 → 24.99 with ThinLTO (+13.2%). These are upstream results, not BB measurements; they do not establish how much of BB's combined improvement comes from each patch. Updated 42 releases also include these improvements. V8 builtins PGO is excluded from the claimed delta because it was already backported to 41.

Other concrete returns:

• Wayland notification activation tokens, demonstrated by the GNOME/KDE tests below.
• Chromium 146 → 152, V8 14.6 → 15.2 and Node 24.15 → 24.20, read from the running binaries. Includes fixes for a Linux environment race/worker memory leak, internal IPC sending-frame validation, and Wayland restore/unmaximize failures. These specific upstream regressions were not reproduced locally.
• New APIs for macOS notification history/group removal, per-WebContents zoom, and cross-platform window state. These enable follow-up BB features and require separate integration; see the linked report for source references.
• Upgrade Electron to 44.3.0 with compatible bundled SQLite #3659's N-API SQLite removes the Electron-ABI-specific prebuild blocker that prevented the runtime upgrade.

Why retain 44 rather than stop at 42? As of September 15, the official schedule gives 42 another 35 support days (October 20), 43 another 112 (January 5), and 44 another 168 (March 2). 41 is already end-of-life. The current stable line receives all fixes; the oldest supported line receives security fixes only. 43 remains a reasonable temporary choice if macOS 12 support is mandatory. Scheduled dates can change.

AGENT GENERATED

[SawyerHood]

This is an automated message. We have closed this pull request because it has been open for more than two weeks.

[salemsayed]

Superseded by #4483: rebased onto current main (b23150d) and re-verified with before/after recordings on GNOME 50.1 and KDE Plasma 6.6.6 Wayland. Current main still loses focus on notification click.

AGENT GENERATED