feat(email): Wire pre_scan_inbox to Triage Dashboard with explicit Refresh

[itomek]

Goal

Replace the dashboard's empty placeholder with real triage data fetched from the existing pre_scan_inbox tool. The Refresh button calls the agent, the response populates the Surfaced column. This is the v0 dogfoodable — a user can land on the dashboard, click Refresh, and see their inbox classified within one click.

Why now

Second sub-issue under #1007. Builds directly on the skeleton from #1008. After this lands, the dashboard is useful even though it doesn't yet remember anything between sessions — the "manually-triggered snapshot" mode from the umbrella's build order.

Scope

• Wire the dashboard's Refresh button to the existing pre_scan_inbox tool path. Reuse whatever client / SSE flow the Agent UI uses today for agent-driven actions.
• Render the returned email_pre_scan envelope into the dashboard:
  • Surfaced column displays urgent + actionable items, sender + subject + reason, with the existing inline action buttons (Reply / Open / Dismiss).
  • Archived this session column — empty until sub-issue 3 wires the state machine; for now, suggested archives surface as a sub-section inside Surfaced.
• Loading state: while a refresh is in flight, show a determinate or indeterminate progress indicator (final styling can iterate in sub-issue 8).
• Error state: if the tool returns ok: false, surface the error inline in the dashboard (don't redirect to chat, don't crash).
• Reuse the row component from EmailPreScanCard.tsx so styling stays in lockstep.
• Last-refreshed timestamp in the header.

Acceptance

• Clicking Refresh fires pre_scan_inbox, loading indicator appears, results populate the Surfaced column on success.
• On error, the dashboard surfaces the error string visibly without crashing.
• Sender / subject / reason display matches the existing card's row shape.
• Reply / Open / Dismiss buttons reuse the same dispatch path as PR #995 (id-only chat-message dispatch via gaia:send-message event).
• No persistence between page reloads — by design; documented in the empty state.
• Lint / TypeScript / build clean; backend tests still pass.
• Dogfoodable: a user with a connected Google account can land on the dashboard and act on at least one suggested archive in under one minute.

Out of scope

• State machine for items moving between columns (sub-issue 3).
• Drafted column populated from draft_reply (sub-issue 4).
• Calendar items (sub-issue 5).
• Auto-refresh / background poll (sub-issue 9).

Depends on

• #1008 — Dashboard skeleton must exist first.
• PR #995 — provides pre_scan_inbox tool + the SSE deterministic-render hook; both reused as-is here.

Refs

• Parent: #1007

[github-actions]

Thanks for filing this — the scope is tight and the acceptance list is unambiguous, which is exactly what this kind of build-order sub-issue needs.

A few notes for whoever picks this up:

Dependency state (as of writing):

• 🟡 #1008 (dashboard skeleton) — still OPEN. Needs to land first per the build order.
• 🟡 PR #995 (engine + pre_scan_inbox tool + EmailPreScanCard.tsx + SSE deterministic-render hook) — still OPEN. Everything this issue reuses lives there. A grep on main confirms neither pre_scan_inbox nor EmailPreScanCard exist yet (src/gaia/agents/email/tools/ has only triage_heuristics, read_tools, reply_tools, organize_tools, delete_tools, calendar_tools — no pre-scan tool). So this issue is correctly blocked until feat(email): daily-driver UI pass — pre-scan card, in-chat Connect, session prefs #995 merges.

Implementation pointers once unblocked:

• The "reuse the existing dispatch path" requirement (gaia:send-message event, id-only chat-message dispatch) is the right call — it keeps the dashboard's action buttons going through the same TOOLS_REQUIRING_CONFIRMATION gating the umbrella (#1007) calls out, instead of inventing a parallel approval path.
• For the loading state, indeterminate is fine for v0 — pre_scan_inbox doesn't expose progress events yet, and sub-issue 8 is explicitly the place for streaming progress UI. Don't fake a determinate bar here.
• Error envelope: matching the existing ok: false shape from the tool keeps the dashboard renderer symmetric with EmailPreScanCard's error path, so the same display component should work in both surfaces.

Small thing worth pinning down before coding:

Archived this session column — empty until sub-issue 3 wires the state machine; for now, suggested archives surface as a sub-section inside Surfaced.

Worth deciding now whether that sub-section is collapsible or just a header divider, since sub-issue 3 will rip it out and a collapsible widget that lives for one sprint is wasted effort. A flat divider seems cheaper.

Frame and dependencies look right — ship #1008 and #995 first, then this.