Fix recurring stuck/unfocusable main window in menu-bar-only mode (#223)

In menu-bar-only mode the app runs as .accessory, where a visible main
window can't become key/active — it shows but can't take focus, so the
whole UI appears frozen (can't navigate or change settings). SwiftUI's
WindowGroup still instantiates the window at launch, and configureWindow
forced it front via orderFrontRegardless(), racing MenuBarManager's
hideMainWindow(). When that race lost, the window stayed visible but dead.

configureWindow now keeps the window hidden when the app is .accessory;
it's shown with .regular policy when opened from the menu bar (the
intended menu-bar-only flow), so a visible window is always focusable.

Co-authored-by: thefourCraft <thefourCraft@users.noreply.github.com>

Author: thefourcraft

native-macos/Zerm/WindowManager.swift

@@ -43,7 +43,19 @@ class WindowManager: NSObject {
         window.setFrameAutosaveName(Self.mainWindowAutosaveName)
         applyInitialPlacementIfNeeded(to: window)
         registerMainWindowIfNeeded(window)
-        window.orderFrontRegardless()
+
+        // Guard the recurring "stuck window" bug. In menu-bar-only mode the app runs as
+        // .accessory, where a visible main window cannot become key/active — it shows but
+        // can't take focus, so the whole UI looks frozen (can't navigate or change settings).
+        // SwiftUI's WindowGroup still instantiates the window at launch, and forcing it front
+        // here races MenuBarManager's hideMainWindow(). If we're .accessory, keep the window
+        // hidden; it is shown with .regular policy when opened from the menu bar.
+        if NSApplication.shared.activationPolicy() == .accessory {
+            logger.notice("configureWindow: app is .accessory (menu-bar-only) — keeping main window hidden to avoid an unfocusable window")
+            window.orderOut(nil)
+        } else {
+            window.orderFrontRegardless()
+        }
 
         // SwiftUI restores ITS OWN autosave frame (keyed by the full view-hierarchy
         // type string) AFTER this method returns, potentially overriding our placement.