feat(email): Calendar items in Triage Dashboard with RSVP actions

[itomek]

Goal

Surface calendar invites in the dashboard with Accept / Decline / Open actions, alongside email triage items. The agent already has list_calendar_events / accept_invite / decline_invite / create_event_from_email tools — this sub-issue gives them a dashboard surface so calendar decisions are part of the same daily-driver flow as inbox decisions.

Why now

Fifth sub-issue under #1007. Builds on the state machine and reuses the existing calendar tools shipped in PR #965. Lands after Drafted (#1011) because the calendar surface is conceptually similar (cards with confirm-gated actions) and reusing the Drafted column's patterns is cheaper.

Scope

• A new dashboard column / strip dedicated to calendar items (placement in the existing 3-column layout is a UX call — could be a fourth column on wide viewports, or stacked below the Surfaced column on narrow ones).
• Pull events via the existing list_calendar_events tool. Same Refresh button as the inbox surface; no separate refresh.
• Each calendar card displays: organizer, title, time window, response status (accepted / declined / pending), conflict warning if it overlaps another event in the fetched window.
• Three actions: Accept, Decline, Open (opens in Google Calendar in a new tab). Accept and Decline gate through the existing TOOLS_REQUIRING_CONFIRMATION confirmation flow.
• missing_organizer flag from the existing tool surfaces visibly (suspicious-invite indicator).
• Invites that came in with email messages (existing create_event_from_email flow) link back to the originating email card on hover/click.

Acceptance

• Calendar column populates from list_calendar_events on Refresh.
• Accept / Decline call the existing tools; confirmation dialog fires; on success state advances and the dashboard reflects the new RSVP status.
• missing_organizer items render with a visible warning (suspicious-invite UX from PR #965).
• Open action launches a new tab to the Google Calendar event view.
• No new tools required; reuses everything from the existing calendar mixin.
• Empty calendar state has explicit copy ("No invites in the next N days") rather than an ambiguous blank column.

Out of scope

• Creating events from email content (existing create_event_from_email is invoked through chat for now; standalone dashboard CTA can land later).
• Multi-calendar support beyond the user's primary Google calendar.
• Outlook calendar — covered separately under provider track #963.

Depends on

• #1010 (state machine + store)

Refs

• Parent: #1007
• Existing calendar tools: PR #965

[github-actions]

Thanks for the well-scoped sub-issue — the dependencies and reuse plan all check out:

• All four calendar tools (list_calendar_events, accept_invite, decline_invite, create_event_from_email) are already shipped in src/gaia/agents/email/tools/calendar_tools.py, and missing_organizer is set in list_calendar_events_impl at line 53. So "no new tools required" is accurate.
• The confirmation flow lives in the existing TOOLS_REQUIRING_CONFIRMATION set used by accept_invite / decline_invite / delete_tools / reply_tools — same path the Drafted column (#1011) will gate through, so the pattern is already proven.
• Dependency #1010 (state machine + store) is still open, so this should sequence after that lands as the issue notes.

🟢 Minor implementation thoughts for whoever picks this up:

• Placement: a fourth column on wide viewports tends to break the symmetry of the existing 3-column layout once a single column gets dense. Stacking calendar below Surfaced (or making it a collapsible right rail) keeps the inbox-first reading order. Worth a quick design check before code lands.
• Conflict warning: detection is straightforward against the already-fetched window, but be explicit about edge cases — back-to-back events (end == start) typically shouldn't flag, all-day events overlapping timed events do.
• Email ↔ invite linking: create_event_from_email results carry the originating message_id, so the hover/click linkback should be a store-level join rather than a separate API call.

Background context for reviewers: docs/plans/email-calendar-integration.mdx covers the broader email + calendar plan this fits into.