fix(linux): make WM_CLASS configurable so app icons resolve in GNOME

[elijah-apprabbit]

First, apologies if I skipped a Contributing doc or missed terms of conduct somewhere, this is my first time contributing to this project and tried my best to follow the standards set. Happy to fix anything or for this to be closed, I just wanted to address an issue that I've faced myself, thank you for an awesome project! :)

On Linux, gnome-shell resolves a window's taskbar/dock icon by matching the X11 WM_CLASS property against StartupWMClass in installed .desktop files. Electrobun hardcodes WM_CLASS to "ElectrobunKitchenSink-dev" in nativeWrapper.cpp, but the CLI generates .desktop files with StartupWMClass set to config.app.name — a permanent mismatch that causes every Electrobun app to show a generic placeholder icon.

This commit:

• Adds a process-global g_linux_wm_class in nativeWrapper.cpp with a mutex-protected setter (setLinuxWmClass) exported via extern "C"
• Replaces the hardcoded literal in both createX11Window and createGTKWindow with the configurable global
• Adds the FFI binding in native.ts and calls it from BrowserWindow.ts at module init, before any window is created
• Adds wmClass to BuildConfigType and ElectrobunConfig's linux block
• Updates the CLI to write wmClass into build.json (defaulting to config.app.name) and use the same value for .desktop StartupWMClass
• Adds no-op stubs on macOS and Windows so the FFI loads on all platforms without platform gating
• Adds wmClass example to the kitchen sink config

Zero-config fix: existing apps get correct icons automatically because wmClass defaults to config.app.name, which already matches what the CLI writes to StartupWMClass. Apps can override via build.linux.wmClass if they need a custom class.