feat(email): Migrate Triage Dashboard task store from session to persistent memory

[itomek]

Goal

Replace the in-session task store from sub-issue #1010 with a persistent backend, so dashboard state — surfaced items, drafted replies, dismissals, learned preferences — survives agent restarts, page reloads, and machine reboots. This is what turns the dashboard from "in-memory snapshot" into a real daily-driver assistant: "I drafted these 4 replies overnight, please approve" stops being a hypothetical.

Why now

Seventh sub-issue under #1007. Per the umbrella's build order, this is the gate between the dogfoodable v0 (sub-issues 1–6) and the always-on assistant. Deliberately positioned after the learnable surfaces are in place so we have something worth persisting; positioned before event triggers / NPU work because those need persistent state to claim "always-on" honestly.

Scope

• Adopt the broader memory subsystem (separate workstream — coordinate with that work's owner before this sub-issue is implementation-ready) as the backing store for the dashboard's task list.
• Migration path:
  • Replace the Zustand-only session store from #1010 with a store that hydrates from memory on agent init and writes-through on state transitions.
  • All existing state transitions (archive / dismiss / draft / send) write through to the persistent layer.
  • Session-preference subsystem from PR #995 (_session_preferences) follows the same migration: init_session_preferences() becomes a loader, mutator tools write through.
  • The user-facing preference tools (set_priority_sender etc.) keep their current signatures — only the storage backend swaps.
• The dashboard's "Drafted overnight" copy stops being a stretch; the count reflects real persisted drafts.
• Conflict-resolution rules surface as memory entries the user can browse / clear (e.g. "agent saw this 3 times, you dismissed each → recorded as low-priority").

Acceptance

• Task store and session preferences both backed by the persistent memory subsystem; restart preserves state.
• On first load after restart, the dashboard hydrates from memory in <1s on a typical inbox state.
• State transitions write through; tested with a kill-the-process scenario (state survives).
• Existing in-session tests still pass against the persistent backend (the contract is the same).
• No changes to the user-facing tool surface — only the backend storage swaps.
• The dashboard's empty-state copy and "wiped on restart" notes from #1010 and #1013 are updated to reflect persistence.

Out of scope

• Cross-device sync.
• Encryption-at-rest beyond what the memory subsystem already provides.
• Migration tooling for users who acted on items in a session before this lands (those items don't carry over — fresh start at deploy time).

Depends on

• The broader memory subsystem (separate workstream). Coordinate before implementation.
• #1010 (in-session task store) — the contract this sub-issue swaps the backend of.
• #1013 (preferences strip — the strip stays, only its data source changes).

Refs

• Parent: #1007
• Multi-model dependency (related but independent): #1000

[github-actions]

Thanks for the careful sequencing — the gating order (this lands after #1010/#1013/#995, before the always-on work) reads cleanly.

A few notes that may help when this becomes implementation-ready:

🟡 Memory subsystem dependency is likely #542 (MemoryStore: SQLite + FTS5) — also touched by PR #606 and the stop-the-line in #903. Worth linking explicitly under "Depends on" so downstream readers don't have to grep for the workstream. If a different store is intended, calling that out would help — there's also Skill auto-synthesis (#887) which builds on top of #606 and might overlap.

🟢 Prior art already in the email agent: src/gaia/agents/email/action_store.py is a persistent SQLite-backed log for reversible mutations (archive, label, draft) used by the existing undo flow. It's a useful reference for the "write-through on state transitions" requirement — the ordering invariant called out at the top of that file (Gmail API call FIRST, record_action on success) is exactly the kind of failure mode the dashboard's persisted state will need to avoid (phantom drafts that never went out, etc.). Worth deciding early whether the dashboard task store reuses this table family or sits as a separate namespace inside the broader memory subsystem.

🟢 Prerequisites not yet shipped: #1010, #1013, and PR #995 (which introduces _session_preferences / init_session_preferences()) are all still open at the time of writing. The "the contract is the same" acceptance criterion only holds if the upstream contracts are stable when this starts — minor flag, but worth a quick check before kickoff.

🟢 Suggestion: add an explicit hydration-failure acceptance row. "Hydrates in <1s" covers the happy path; the case where the memory layer is unreachable / corrupt isn't covered. Per CLAUDE.md's no-silent-fallbacks rule, the dashboard should fail loudly on hydration error rather than render an empty list as if the user has zero items — that's the exact kind of regression silent fallbacks hide.

cc @kovtcharov-amd for the memory-subsystem cross-ref since #903 sequences merges around #606.