fix: restore Cmd+W as File > Close Window on macOS

[ole-tidal]

Why

⌘W is one of macOS's oldest system-wide conventions: File > Close Window closes the focused window of the active app. It works in Finder, Safari, Slack, Discord, Notes — everywhere — and decades of muscle memory press it dozens of times a day. In Buzz it silently did nothing.

That was a deliberate hijack, not an accident: app_menu.rs removed the default close_window items Tauri installs, because macOS resolves a menu key equivalent before the webview receives any key event, so while the item existed Buzz Term could never bind ⌘W to "close this terminal tab". Removing the item fixed the terminal-local conflict by breaking a standard OS chord app-wide — every non-terminal surface of the app stopped honoring it. That trade is backwards: an app-specific feature should never win over a platform-wide convention.

For a tray-resident app, "close the window" means hide-to-tray — exactly what the red traffic-light button already does via the CloseRequested interception in lib.rs, and the same ⌘W behavior as other tray-resident chat apps.

What

• Restore File > Close Window (⌘W) as a custom menu item (predefined items cannot be toggled after creation).
• The item closes the focused window through the normal CloseRequested path — the main window hides to tray, huddle windows keep their drawer-restore behavior. Falls back to the main window when no webview window reports focus.
• New set_close_window_menu_enabled command: Buzz Term disables the item for exactly as long as it owns the keyboard. A disabled menu item does not consume its key equivalent, so ⌘W falls through to the webview and the terminal's close-tab chord (matchTabChord) keeps working. TerminalSubstrate already tracks ownership; it now syncs the menu item on every ownership flip and re-enables on unmount.
• The Window submenu's duplicate close item is deliberately not restored — File is the chord's canonical home.
• Unit test for the ownership → enabled mapping (closeWindowMenuEnabledFor).

Verification on a local build

Tested against a locally built instance (just desktop-standalone), driving the real app pid-exactly over the Accessibility API:

• File > Close Window present with cmd char W, modifiers 0 (plain ⌘), enabled by default.
• ⌘W key event delivered to the app: window hides to tray (AX window count 1 → 0), process stays alive.
• Clicking the menu item does the same.
• Not coverable in standalone mode: the terminal-owned disable span (needs a live community + Buzz Term session). That mapping is unit-tested, and the enable/disable command is a thin set_enabled wrapper.

Note: the follow-up native-lifecycle PR (#4876) builds on this branch (both touch app_menu.rs). It targets main and includes this PR's commit until this one merges.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5aebbccaf2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Re-enable Close Window when the main window blurs

When the terminal panel is open in the main window, this effect disables File > Close Window for the entire macOS application menu, not just the main webview. If the user then focuses a separate huddle companion window (huddle-*, whose CloseRequested path restores the drawer), Cmd+W is still globally disabled, so the new close_focused_window menu handler never runs and the focused huddle window cannot be closed until the terminal panel is closed or returns to Buzz ownership. Please gate the disable state on the main window actually being focused, or re-enable it on blur.

Useful? React with 👍 / 👎.

[ole-tidal]

🤖 Closing at the reporter's request alongside the companion lifecycle PR (#4876) — the reporting machine's window-manager issue was resolved externally and the reporter opted not to pursue these changes.