chore(deps-core): update electron to v43.4.1 [DO NOT MERGE: regression persists]

[afonsojramos]

Warning

Do not merge. The premise of this PR did not hold. Kept as a draft because it is the evidence that 43.4.1 does not fix the Linux tray regression. See Result.

Original intent

Bump electron 43.2.0 → 43.4.1 to skip the Linux tray regression in 43.4.0, on the assumption that electron#52952 (shipped in 43.4.1) fixed it:

Fixed Tray icons not appearing (and their menus not opening) on Linux desktops that address the StatusNotifierItem by its unique D-Bus name or via the org.freedesktop.StatusNotifierItem interface.

Result

That assumption was wrong. 43.4.1 fixes part of the problem but the tray icon still never paints.

Job	Attempts over 60s	exactTray	Result
Linux (Budgie)	20	0 on every attempt	fail
Linux (Sway/Waybar)	29	0 on every attempt	fail
Linux (LXQt)	28	0 on every attempt	fail (new in 43.4.1)

What 43.4.1 did fix: waybar's [error] Invalid Status Notifier Item: ... no longer appears (present exactly once on 43.4.0, zero times on 43.4.1). So electron#52952 landed and corrected the SNI-addressing fault. The icon still does not render, so at least one further defect remains.

LXQt is a new failure: it passed on both 43.2.0 and 43.4.0, and fails on 43.4.1.

Version correlation, with a same-day control

All three runs below use the identical harness and workflow on ubuntu-24.04, on the same day, ruling out runner-image drift:

Run	Electron	Budgie	Sway/Waybar	LXQt
main @389a8a3, 11:43	43.2.0	pass	pass	pass
#143 rebased, 11:47	43.4.0	fail	fail	pass
this PR, 14:30	43.4.1	fail	fail	fail

In every failing case the popover window renders correctly (Budgie: windowWhite=16734 windowBlack=3200, the exact expected counts) and only the tray icon is absent, so this is specific to tray rendering rather than general painting. The retry loop added in #153 exhausts rather than recovering, which rules out a timing race.

Consequence

electron should stay pinned at 43.2.0 until this is resolved upstream. #143 (43.4.0) and this PR (43.4.1) should both stay unmerged.

Upstream

Already tracked, so no new issue was filed:

• electron#52674 (open) — "Appindicator receiving no response from Electron 43.3 applications". Same signature: last-working 43.2, broken from 43.3.0.
• electron#53024 — closed as a duplicate of the above.

Root cause per the upstream analysis: Chromium's new StatusNotifierItem multiplexer collapses every icon onto a single /StatusNotifierItem object path, so the only remaining discriminator is the destination service name. Desktops that address the item by its unique D-Bus connection name (anything built on Gio.DBusProxy) can no longer be routed to the right icon, because Multiplexer::GetIcon(":1.134") finds nothing. The old code gave each icon its own object path and D-Bus routed by path, which worked under either name form. Arrived via electron#52416 (Chromium 150.0.7871.181).

electron#52952, the 43.4.1 change this PR was based on, is described upstream as a bad fix for the same problem. That matches what we measured: it removed waybar's Invalid Status Notifier Item error without making the icon render, and coincided with LXQt breaking.

Our matrix adds data the upstream issue does not yet have: Budgie, Sway/Waybar and LXQt are also affected (upstream names GNOME's AppIndicator extension and xApp), KDE Plasma is confirmed unaffected, and 43.4.1 does not resolve it. Failures reproduced on re-run.