[Meeting Assistant] PR-7: In-call approval + execution + speak (Phase 2) #3513

Part of #3505 · PR-7 · Phase 2 · Depends on PR-6 · Backend-blocked: YES (bot:speak)

Approve and execute in-call requests, with an approval model that works when the user isn't looking at the screen.

Scope

• Dual-channel approval for in-call tool execution (per the "always require approval" decision):
  1. Post ApprovalRequestCard in the meeting thread (visual, for later).
  2. Emit bot:speak { text: "I'd like to <action>. Say 'approve' to confirm." }.
  • First response wins: voice (next bot:in_call_request whose commandText parses via existing parse_approval_reply, approval/gate.rs) or the thread card (approval_decide). Timeout: 2 min (shorter than the standard 10-min TTL).
  • On approve → execute_dispatch, post result in thread, optional bot:speak confirmation. On deny/timeout → post denial + bot:speak "Okay, I won't do that."
• approval/gate.rs: add task-local InCallApprovalContext { meeting_id, correlation_id } (mirrors existing APPROVAL_CHAT_CONTEXT); when set, intercept() emits bot:speak alongside the card and listens for a voice decision.
• Example end-to-end: "schedule a follow-up in 40 min" → GOOGLECALENDAR_CREATE_EVENT → approval → event created → link posted to thread + verbal confirm; allow inviting attendees.
• Frontend: backendMeetSlice pendingInCallAction; show "Waiting for approval: " in MeetingBotsCard.tsx.

Contracts

• Reuses openhuman.approval_decide; outbound bot:speak (from PR-6).

Tests

• Rust: voice-approve path, card-approve path, deny, timeout. Vitest: pending in-call action state.

Acceptance

• An in-call request can be approved by voice or thread card, executes the tool, posts the result, and (optionally) confirms verbally — never executing without approval.