Epic: Google Meet Meeting Assistant — proactive join, notes, summaries & in-call agency (Phase 1 + 2) #3505

Turn the existing Google Meet bot (backend Recall.ai/Camoufox bot driven via Socket.IO, core domain src/openhuman/agent_meetings/) into a proactive meeting assistant, then add in-call agency.

This is the tracking epic. Work is sliced into dependency-ordered sub-issues, each independently shippable behind a config flag.

Phase 1 — proactive meeting assistant

1. Calendar-triggered auto-join — watch Google Calendar; when a meeting with a Meet link is ~30 min away (and a "happening now" check), notify the user: "You have a call — add OpenHuman?" with Yes / No / Always.
2. Muted listener — bot joins mic-off, listen-only, captures the full transcript.
3. One thread per meeting — a dedicated chat thread per meeting, tagged with a "Meetings" label, titled from the calendar event, with the transcript posted into it.
4. Proactive summary — after the call, offer to summarize; on yes, generate + post a structured summary.
5. Tool-aware actionables — extract action items, classify each against the user's connected tools: executable → approval card ("create Notion task — do it?"), non-executable → advice-only. All executable actions always require explicit approval.

Phase 2 — in-call live agency

6. During a live call, the user can address the bot by voice ("Hey Tiny, schedule a follow-up in 40 minutes"). The bot detects the request in real time, routes it through the orchestrator with live meeting context, runs a clarification loop if needed, gets approval (spoken "approve" or thread card), executes, posts the result to the thread, and optionally confirms verbally.

Confirmed product decisions

• Auto-join: default Ask each time; Always option available from day one (auto_join_policy: AskEachTime | Always | Never).
• Which meetings: any calendar event with a Google Meet link (no organizer/acceptance filtering).
• Threads: one new thread per meeting, tagged with a "Meetings" label (reusing the existing thread-label system).
• Actionables: always require an explicit approval click (no silent execution, even for whitelisted tools) — in both phases.
• Auto-summarize: Ask | Always | Never, default Ask.

Foundational design — the meeting_id

A single correlation ID threads the whole journey: calendar event → join request → returned transcript → meeting thread → (Phase 2) live in-call requests. This is the missing link today (the backend transcript can't currently be tied back to a specific meeting) and drives the two small backend asks below.

Roadmap (dependency order; each shippable behind a flag)

Unblocked now (no backend needed): PR-0 (#3506), PR-1 (#3507), PR-4 (#3510), PR-5 (#3511).
Backend dependency: #3514 unblocks PR-3 (Phase 1) and PR-6/PR-7 (Phase 2).

Backend asks (see backend-contract sub-issue)

• Phase 1: accept correlationId + listenOnly on join; echo correlationId back on every bot:* event.
• Phase 2: a live mid-call command channel (bot:in_call_request) + an optional "speak into the call" capability (bot:speak).

Conventions

Canonical domain module shape, controller schemas wired via src/core/all.rs, ≥80% diff coverage, i18n parity across all 14 locales, verbose debug logging, no business logic in src/core.