fix(macos): raise Preferences after Browse so it stays in front - #283

Bug

Clicking any Browse button inside Preferences on macOS visually closes the whole Preferences dialog, on both file-picked and Cancel. Reproduces on the pre-existing video-player picker (IDC_BROWSEV), the browser picker (IDC_SELBROWSER), and — once #280 lands — the ffprobe path picker (IDC_MEDIAMETA_FFPROBEBROWSE). Windows (wxMSW) and Linux (wxGTK 3.2) don't reproduce.

Root cause

Not a close event we were mishandling. Debug-tracing showed:

• Before wxFileSelector: IsShown() == true, IsBeingDeleted() == false
• After wxFileSelector (Cancel): str == "", IsShown() == true, IsBeingDeleted() == false
• OnClose never fires

So the dialog was still logically alive after the file selector returned — it just wasn't visible. Cmd+Tab back to aMule confirmed it: the Preferences window was ordered behind the main aMule window. The modal NSOpenPanel that wxCocoa opens steals key-window status while shown; when it dismisses, Cocoa returns focus + Z-order to whichever aMule window was active before Preferences opened, not to Preferences itself.

Fix

Raise() on the Preferences dialog after wxFileSelector returns, macOS-only. Restores Z-order so the dialog sits in front of the main window where the user left it.

wxString str = wxFileSelector(title, "", "", "", wildcard, 0, this);

#ifdef __WXMAC__
    // wxCocoa quirk: the modal NSOpenPanel steals key-window status;
    // when it dismisses [...] Raise() restores its Z-order.
    Raise();
#endif

Wrapped in #ifdef __WXMAC__ so wxGTK / wxMSW pay nothing — they don't reproduce the bug (Windows CommonDialog is a real top-level, wxGTK's file dialog doesn't reshuffle Z-order the same way).

Verified

Local build + retest on macOS 15 ARM64: Preferences → Files → any Browse button → Cancel now leaves Preferences in front. Same for Open. Windows / Linux behaviour unchanged (Raise() is a no-op there, but the #ifdef guards against paying the call at all).