fix: value-initialize NOTIFYICONDATA and clear hIcon after destroy

[JulianPscheid]

Two problems in the Windows plugin, both stemming from nid never being initialized.

Uninitialized szTip becomes the tooltip

nid and niif are declared without initializers. On the first setIcon() call, _ApplyIcon() copies nid.szTip into a backup before it zeroes the struct, restores it afterwards, then sets NIF_TIP if the first byte is non-null:

WCHAR szTipBackup[128];
StringCchCopy(szTipBackup, _countof(szTipBackup), nid.szTip);

ZeroMemory(&nid, sizeof(NOTIFYICONDATA));
...
StringCchCopy(nid.szTip, _countof(nid.szTip), szTipBackup);
nid.uFlags = NIF_MESSAGE | NIF_ICON;
if (nid.szTip[0] != '\0') {
  nid.uFlags |= NIF_TIP;
}

That backup reads uninitialized memory. When those bytes happen to be non-zero, NIF_TIP gets set and Windows renders them as the tooltip. One of our users hovered the tray icon and saw a truncated copy of their PATH. Apps that call setToolTip() overwrite the garbage and never notice, but an app that never sets a tooltip will show whatever was in that memory.

hIcon left dangling after DestroyIcon

Destroy() and the WM_DESTROY handler both call DestroyIcon(nid.hIcon) without clearing the handle afterwards. SetIcon() checks nid.hIcon != nullptr before destroying the old icon, but since nothing ever sets it back to null, a destroy followed by re-initialization calls DestroyIcon twice on the same handle. If Windows recycled that handle value in between, the second call frees an unrelated icon.

Value-initializing both members fixes the first problem and makes the existing null check in SetIcon() meaningful. Clearing hIcon at both destroy sites fixes the second.