perf(desktop): stop beachballs on agents menu and thread open

[wesbillman]

Why

Users still hit macOS beachballs after the #1338 scroll/perf work. #1338 fixed the cold-mount cost of building hundreds of message rows (a synchronous markdown-parse longtask). But the remaining reports — a 2-message thread ("size doesn't matter") and the agents menu / start-stop / edit — are a different, count-independent class of main-thread block. This PR fixes both.

Investigation writeup: RESEARCH/BEACHBALL_SECOND_PASS_2026_06_30.md (in the Buzz workspace).

Two root causes, two fixes

A) Agents menu / start / stop / edit — blocking Tauri commands on the main thread

In Tauri v2, a synchronous #[tauri::command] pub fn runs on the main UI thread; only async fn commands get a worker thread. The agent/persona/team commands were sync and did blocking disk I/O + per-process liveness syscalls there. list_managed_agents (agents-menu mount, and refetched after every start/stop/edit) reads agent + persona records from disk, syncs every child process, and builds a per-agent summary — a multi-hundred-ms freeze.

Fix: convert 14 of them to async fn + tokio::task::spawn_blocking, matching the existing pattern (deploy_to_provider, probe_backend_provider). State is re-derived from the owned AppHandle inside the closure (State<'_,_> is borrowed and std::sync::MutexGuard is !Send). The managed_agents_store_lock still serializes the on-disk store, so consistency is unchanged. IPC-transparent: the frontend already awaits these; only the Tauri-injected state param was dropped (never sent from JS).

Converted: list_managed_agents, stop_managed_agent, delete_managed_agent; list_personas, create_persona, update_persona, delete_persona, set_persona_active; list_teams, create_team, update_team, delete_team, install_team_from_directory, sync_team_directory.

Left sync on purpose: reconcile_inbound_persona_event + put_agent_session_config (background per-relay-event paths — async-per-event adds overhead/ordering risk for no UX win), parse_team_file/parse_persona_files (pure CPU, rare import), and the trivial log/settings reads.

B) Opening a thread forced the whole channel reflow into the click task

Opening a thread doesn't unmount the channel timeline; the timeline (up to 2000 rows) and the thread panel are siblings in one flex-row, so opening the panel shrinks the timeline's width and reflows it — a cost that scales with the channel behind the panel, not the 2-message thread. handleOpenThread wrapped the optimistic open in flushSync, which forced that whole reflow to run synchronously inside the discrete click task, blocking paint.

Fix: remove the flushSync from the thread open/close path and move the panel-state batch behind a yielded setTimeout(0) + React.startTransition, so the expensive mount + width reflow no longer blocks the click. (desktop/src/features/channels/useChannelPaneHandlers.ts)

Validation

• A (Rust): just desktop-tauri-check ✅, rustfmt ✅, 850 tauri unit tests pass ✅. (Local desktop-tauri-clippy shows 6 errors that all pre-exist on clean main in untouched files; this diff adds none. Tauri clippy is not a CI gate.)
• B (frontend): pnpm typecheck ✅, pnpm build ✅, pnpm check ✅, plus smoke e2e: messaging.spec.ts "opens a single-level thread panel" ✅ and navigation.spec.ts "thread panels" ✅.

Authorship

Two commits, both DCO-clean (authored Wes, signed-off Wes): cause A co-authored Brain, cause B co-authored Pinky.