fix: ignore transient post-show blur on Windows tray click

[afonsojramos]

Problem

On Windows, gitify v7 users report that clicking the tray icon does nothing: the app runs in the background (notifications fire, the icon is colored) but the popup window never appears, with no errors logged. See gitify-app/gitify#3064.

Root cause

Clicking a tray icon on Windows keeps the shell (explorer.exe) as the foreground process. Because of Windows' foreground-activation lock, the popup's show() cannot pull focus to itself, so the window immediately receives a blur. The existing blur handler schedules the 100 ms auto-hide, which fires before the first paint, and the window hides itself again. Net effect: the click appears to do nothing.

This is timing-sensitive, which is why it reproduces on some Windows setups and not in CI (headless runners have no real shell/foreground contention).

Fix

Ignore blur events that land within a short grace window (400 ms) immediately after a show(). A genuine click-away arrives well after the popup has settled, so it still auto-hides as before. The guard is gated to win32, so macOS and Linux behaviour is unchanged.

Also split the pre-existing isAlwaysOnTop() ? … : … ternary into explicit if branches so the new early-return reads cleanly; the pinned/focus-lost path is unchanged.

Tests

Added a blur-to-hide behavior suite covering:

• non-Windows: blur still hides ~100 ms later (unchanged)
• Windows: the transient post-show blur is ignored (the #3064 repro)
• Windows: a blur after the grace window still hides (real click-away)
• pinned alwaysOnTop still emits focus-lost instead of hiding

Verified the Windows test fails if the guard is removed. pnpm test (72 passing), pnpm typecheck, and pnpm lint:check are all green.

Downstream

Once released, bump electron-menubar in gitify and the app-level workaround in gitify-app/gitify#3082 can be dropped in favor of this source fix.