Add real background/tray mode (don't kill agent sessions on window close)

[abduosmanaj]

Problem

Closing the Buzz Desktop main window (the X button) terminates buzz-desktop.exe
and all of its child buzz-acp.exe agent-session processes immediately.
Minimizing works fine and keeps everything alive, but there's no tray icon /
"minimize to tray" registration, so closing the window is the only way to
"get it out of the way" -- and it kills every running agent session.

Steps to reproduce

1. Have one or more agent sessions active in Buzz Desktop.
2. Close the main window with the X button (not minimize).
3. Observe: buzz-desktop.exe and all buzz-acp.exe child processes exit;
   agent sessions stop.

Expected

A background/tray mode (similar to Tailscale, OneDrive, etc.) so closing the
window doesn't kill in-progress agent work -- e.g. a system tray icon with the
window continuing to run minimized/hidden until the user explicitly quits.

Environment

• Windows 11
• Confirmed via Task Manager: no tray icon registered for buzz-desktop;
  buzz-acp.exe processes are direct children of buzz-desktop.exe and exit
  when the parent window is closed.

[mgonzalezdidesa]

Confirming this on macOS 15 (Darwin 25.5.0), Buzz Desktop, Apple Silicon — so it isn't Windows-specific. Same behavior, same cause, and I have unified-log evidence for the exact sequence.

A user clicked the red close button while several agent sessions were running. The app terminated ~3.3 s later, taking every session with it. From log show --predicate 'processIdentifier == 70488' (buzz-desktop):

19:39:15.008  (AppKit) trackMouse send action on mouseUp
19:39:15.009  window <TaoWindow: 0x7fc9b2613b70> windowNumber=1abf windowShouldClose: prevented close
19:39:18.457  CMIO_DAL_CMIOExtension_PlugIn.mm ... AtExit has already fired
19:39:18.466  [com.apple.CoreAnalytics:client] Entering exit handler.
19:39:18.466  [com.apple.CoreAnalytics:client] Exiting exit handler.

Two things worth noting in that trace:

1. windowShouldClose: prevented close — the Tauri window (TaoWindow) does intercept the AppKit close, so the hook is already there. It just proceeds to tear down the whole process instead of hiding the window. The interception point needed to fix this exists today.
2. The exit is clean — atexit handlers ran, window state was persisted. This is a deliberate exit(), not a crash. No .ips crash report is generated, which is also why it looks to the user like the app "closed itself for no reason."

Filtering the full hour before the exit for the same event, there was exactly one trackMouse / windowShouldClose pair, and no miniaturize event — so the close path is unambiguously what fired.

The ergonomics angle, which I think raises the severity: on macOS the red close button sits ~20 px from the yellow minimize button. As @abduosmanaj notes, minimize keeps everything alive and close destroys everything — with no dialog, no undo, and no crash report to explain it afterwards. In our case the user was aiming for minimize. A 20-pixel miss silently killed in-flight agent work.

So there are really two fixes, and the cheap one is worth doing even before the tray work:

• Short term: when one or more agent sessions are active, intercept the close (the prevented close hook above already fires) and show a confirmation — "N agent sessions are running. Quit anyway?" Most apps with work in progress do this, and it turns a destructive misclick into a recoverable one.
• Long term: the real background/tray mode this issue asks for.

Happy to test a patch on macOS if that's useful.

[nikeruga]

기능 요청: Windows 시스템 트레이 상주와 백그라운드 알림

Windows에서 Buzz를 업무용 메신저처럼 사용할 수 있도록 다음 동작을 요청합니다.

1. ‘닫을 때 시스템 트레이로 숨기기’ 옵션을 제공해 주세요. 활성화한 경우 X 버튼은 창만 숨기고 메시지 수신을 유지해야 합니다.
2. 시계 옆 시스템 트레이 아이콘에서 ‘Buzz 열기’와 ‘완전 종료(Quit)’를 제공해 주세요.
3. 창이 숨겨진 상태에서도 사용자가 허용한 멘션·DM·참여 스레드 답글이 Windows 알림으로 전달되고, 알림 클릭 시 해당 대화가 열리게 해 주세요. 음소거와 알림 해제 선택은 존중해야 합니다.
4. 트레이 설정과 알림 설정을 앱 재실행 후에도 유지하고, 명시적 Quit이나 Windows 종료·업데이트는 정상 처리해 주세요.

검증 시나리오: X로 숨기기 → 새 멘션 알림 수신 → 알림 클릭으로 대화 열기 → 재실행 후 설정 유지 → Quit으로 실제 종료.

트레이 제안 #6893과 알림 관련 #2445, #4660, #7275, #6876을 함께 검토해 주시면 좋겠습니다. 트레이 상주와 알림 권한 처리는 별개이므로 두 기능 모두 정상이어야 위 흐름이 완성됩니다.

중복 이슈 대신 기존 요청에 필요한 동작을 추가합니다. 감사합니다.