zarvis: dismiss stale approval prompts when another client answers

[edwin-zvs]

Bug

When a zarvis session shows a tool-approval prompt, the web UI shows an approval dialog. If the user answers the prompt from the TUI (or the session's PTY, or another browser), the web dialog stays open and never closes — the decision was already made, but the passive copy lingers.

Root cause

The daemon broadcasts ToolApprovalRequest to all clients, but there was no event signaling that an approval was resolved. A client only closed its prompt when it made the decision; it never learned that another client answered.

Fix

Add a transient SessionEvent::ToolApprovalResolved { call_id }:

• zarvis adapter (interactive.rs + agent.rs) emits it at every approval exit — approve / deny / auto-review→approve / unsafe-auto / stop / interrupt — so it fires regardless of how the prompt was answered (PTY keystroke or tool_decision RPC).
• daemon (session.rs) broadcasts it live but never persists it to the transcript (same fast-path treatment as BrowserPreview / AgentStatus).
• web UI (index.html) — new resolveApproval() closes the dialog / drops the queued entry when the call_id matches.
• TUI (app.rs) — new dismiss_approval_prompt() clears the minibuffer approval prompt on the same signal, fixing the identical latent bug there.

Test

• New daemon test tool_approval_resolved_is_not_persisted_to_transcript (broadcast-but-not-persisted).
• Adding the SessionEvent variant was compiler-guided across all exhaustive matches (cli rendering/rain/scroll classifiers → hidden/none).
• All affected suites pass: protocol 61, adapter-zarvis 149, agentd-cli 223, daemon all green; workspace builds clean.

Binaries touched

agentd (daemon broadcast + bundled web UI), agent (TUI), agentd-adapter-zarvis (emits the event).

Note

Verified the Rust side via tests; the browser dialog change itself wasn't exercised live in a browser (straightforward state/DOM update).

🤖 Generated with Claude Code