fix(desktop): restore tray-only window behavior

[mauropereiira]

This PR was implemented by an AI agent working interactively under @mauropereiira's direction. The diff and test results were reviewed before submission.

Issues

Fixes #3705.

This also restores close handling that was removed unintentionally while window and tray code were reorganized in #3779.

Description

Harper previously intercepted close requests for Editor and Settings, prevented destruction, and hid those windows. After #3779, the red close button destroys the window instead. The main process also remains a regular macOS application while tray-only, leaving a permanent Dock icon.

This change:

• Restores CloseRequested -> prevent_close -> hide for Editor and Settings.
• Switches macOS to Accessory activation policy when Harper starts tray-only.
• Switches to Regular before showing Editor or Settings.
• Returns to Accessory after the final visible user window is hidden.
• Keeps Regular while another Harper window is visible or minimized.
• Unminimizes existing windows before showing and focusing them from the tray.
• Leaves the yellow minimize button's native Dock behavior unchanged.
• Leaves tray Quit and Command-Q on Tauri's normal exit path.

No Dock preference, single-instance plugin, reopen handler, or tray refresh changes are included.

Demo

The built macOS app reported Regular activation policy (0) while Settings was visible and Accessory (1) after a tray-only relaunch. The parent and highlighter processes remained active in tray-only mode.

How Has This Been Tested?

• cargo check -p harper-desktop --all-targets
• cargo clippy -p harper-desktop --all-targets -- -D warnings
• cargo test -p harper-desktop --lib (52 passed)
• just format
• just check-desktop on a combined branch containing all three desktop fixes
• Built and launched an Apple Silicon .app bundle with Tauri
• Manually verified Regular policy with Settings visible and Accessory policy on tray-only startup

The native red-close and yellow-minimize interactions still need a final hands-on pass because synthetic clicks are blocked by macOS Accessibility permissions in the test shell.

AI Disclosure

• I am a human and didn't use any AI.
• I used LLM features of my editor, but not an agent.
• I consulted one or more coding AIs, but didn't use an agent.
• I used an AI agent interactively.
• I am an agent or I got an agent to do the work autonomously.

If Your PR Implements or Enhances a Linter

Not applicable.

Checklist

• I have performed a self-review of my own code
• I have added tests to cover my changes
• I have considered splitting this into smaller pull requests.

[elijah-potter]

You've adjusted the behavior so that "closing" a window simply hides it. Can you articulate why this behavior is desired?

I only ask because I personally prefer my windows to fully close. This is especially true since the WebViews these windows occupy are pretty heavy.

[mauropereiira]

Might be from what I'm used to? The behavior I was aiming for is the usual menu-bar app distinction where the red button dismisses Harper’s window and returns it to menu-bar-only mode, while the yellow button minimizes the window and keeps it in the Dock. Harper’s background service continues running either way. Plus quit from the tray or Command-Q still exits the app.

Also, while doing this PR I found that there might also be a practical reason to keep the editor window alive right now. Its text is held in the WebView and isn’t persisted elsewhere, so destroying the window means reopening an empty editor. Hiding it preserves the current document. This was also Harper’s behavior before #3779, so the PR restores that! 😬

I'm not the best coder (not close to it), so I asked the agent that did this and it said:

You’re right about the cost of retaining the WebViews, though. Settings doesn’t have the same unsaved-document concern, so a reasonable compromise would be to hide the editor but fully close Settings. Longer term, persisting the editor state would let us destroy that WebView too without losing work.