Linux daemon path ignores configured appIcon; installer hardcodes Icon=utilities-terminal in the notification desktop entry

Environment: plugin v1.40.1 (commit 74b9fba), Fedora 44, GNOME Shell 50.4 on Wayland, click-to-focus daemon active and healthy.

Symptom: every notification shows the generic utilities-terminal stock glyph instead of the bundled Claude icon, even with notifications.desktop.appIcon set (default ${CLAUDE_PLUGIN_ROOT}/claude_icon.png, file present).

Cause (two halves):

1. The configured appIcon never reaches the Linux daemon path. SendDesktop() resolves and validates it (internal/notifier/notifier.go), but sendViaDaemon(title, body, cwd) has no icon parameter (internal/notifier/terminal_linux.go:52-71), and the daemon's handleNotification() builds the notify.Notification with no icon field at all (internal/daemon/server.go:262-274). The icon is only used by the beeep fallback — dead code whenever the daemon is healthy, i.e. in normal operation.
2. With no icon in the D-Bus call, GNOME resolves identity via the desktop-entry hint, which on GNOME/Wayland always points at the hidden claude-notifications.desktop — and install_linux_notification_desktop_entry() hardcodes Icon=utilities-terminal into it (bin/install.sh:1579). The value is not sourced from config, so appIcon is silently a no-op on this platform.

Suggested fix: thread appIcon through the daemon IPC and set it on the notification, and/or generate the desktop entry with the bundled claude_icon.png (ideally configurable). Either alone would fix the visible symptom; both would make behavior match the config's promise.

Workaround used locally: hand-editing the generated desktop entry to Icon=<abs path to a copy of claude_icon.png> works, but is reverted by every reinstall/update since the installer regenerates the file verbatim.