Binary builder action

[noideaman]

Created a action workflow for building windows and linux binaries/installers

Changes

• updated electron to latest (43)
• updated electron-builder to latest (26.15)
• changed build section to not run electron-builder
• added values for linux (icon/compression/target output type)
• updated windows values (target output type)
• added a png of the icon for linux use
• added multiple resolutions to the windows icon

New with actions file

• builds windows and linux binaries/installers
• run on creation of new release
• uploads built binaries both to actions artifacts and releases

I tried using electron-builder's built in publisher tool. but i could not get it to work properly so it builds with --publish=never and a different action handles publishing it

[noideaman]

it runs and claims connections, but it aint oscing, atleast on linux, binaries are on my fork

[noideaman]

so it looks to be an osc and oscquery mdns issue
#34

[ComfyChloe]

Heads up — this PR overlaps with the auto-update tracking issues, specifically #38 (Phase A: CI workflow + GitHub Releases manifest). A few things worth aligning before merging:

Version delta vs the auto-update plan:

• This PR moves \electron-builder\ to 26.15. The auto-update plan currently pins \electron-updater@~8.0.0\ as the peer of \electron-builder@25.1.0. \electron-updater\ 8.x is not guaranteed compatible with electron-builder 26 — if Phase A lands first, we'll need to verify \electron-updater\ against 26.15 and possibly bump to a newer major.
• Electron bump to 43 should also be validated against the pinned updater before merge.

Publisher choice:

• This PR uses --publish=never\ and a separate action for uploads. That's fine for raw binary distribution, but Phase A (Auto-update Phase A: CI workflow + GitHub Releases manifest + verification gates #38) is built around \electron-builder publish: github\ so \latest.yml\ lands alongside the .exe\ in the same workflow step. If we adopt this PR's pattern, the publish step in Phase A becomes a separate action that also has to copy \latest.yml\ (and \latest-beta.yml\ for beta) into the release assets.
• Whichever pattern lands first constrains the other — worth deciding before either merges.

Linux target:

• The auto-update plan's v1 scope is NSIS per-user Windows only (see Auto-update Phase A: CI workflow + GitHub Releases manifest + verification gates #38 decisions §1). Linux/portable \dir\ builds are explicitly out of scope for v1. This PR adds Linux \deb/AppImage-style targets, which is forward-looking but not part of the current auto-update rollout — they need a separate updater path or have to wait for v2.

NetApp file:

• The Linux icon needs to be a proper .png\ with valid dimensions, not a renamed .ico\ or a low-res preview. Verify the file actually renders in AppImage / .deb\ package managers before merge.

Worth either resolving these against #38 before merging, or coordinating a merge order so #38 lands first and adjusts to the new electron-builder version. Either works — just don't want both to land and then need an emergency electron-updater pin bump.

Cross-referenced from #38 (Phase A).