feat(macos): bring reconnect forward when a UI surface opens mid-backoff

[MegaManSec]

What

After #16 added exponential reconnect backoff (15 s -> 5 min ceiling), a disconnected bulb could sit on a multi-minute backoff with no quick way to hurry it short of hitting Reconnect. Opening the menu-bar dropdown only called refreshIfConnected, which is a no-op while disconnected.

This treats opening a UI surface as a fresh chance to reach the bulb -- but only when we're actually mid auto-reconnect:

• Connected -> re-read the bulb's values (unchanged).
• Mid auto-reconnect (dropped, not manually disconnected) -> reset the backoff and pull the next attempt forward (~0.5 s), so you don't wait out a backoff grown to minutes.
• Manually disconnected (or no light) -> left alone. Opening the menu never resurrects a deliberate disconnect -- the same invariant the poll and network-change paths already honour.

How

• Renamed the shared open handler refreshIfConnected -> refreshOnOpen and added the mid-reconnect branch. The bring-forward reuses the exact resetReconnectBackoff() + scheduleNextPoll(after: 0.5) that handlePathChange uses on a network change, and relies on pollTick's existing guards so it can't stack onto an in-flight connect.
• Wired into both open events that shared the old method: the menu-bar dropdown (menuWillOpen) and the controls window's onAppear (still gated on autoSync).

Testing

• swift build -- clean
• swift test -- 15/15 pass
• Timing path (DispatchSource/NWPathMonitor) isn't covered by the suite, so the bring-forward was reasoned against the existing handlePathChange flow rather than unit-tested.