Proposal: add Fathom as a selectable meeting-intelligence provider (alongside Granola)

[Anou4r]

Meeting intelligence currently runs on Granola. I'd like to propose adding Fathom as a selectable alternative, so users can pick whichever meeting provider they already use. A lot of teams already run on Fathom (it auto-records and transcribes Zoom / Meet / Teams), and today they get no meeting intelligence in Dex unless they also adopt Granola.

I've built and run a working Fathom integration in my own vault for a few weeks: a remote claude.ai MCP connector (.claude/mcp/fathom.json, OAuth via /mcp) with /process-meetings reworked to pull on-demand. No Python server, no .env key, no background daemon, no local cache. The catch is that in my vault it currently replaces Granola, whereas for upstream the right move is to make the backend a choice: a meeting_intelligence.provider field in user-profile.yaml (granola | fathom | none), with Granola staying intact and the default, and /process-meetings plus onboarding branching on it.

Before I open a PR I wanted to align on the design: is a simple provider switch the direction you'd want, or a fuller abstraction layer, and what config shape do you prefer? If there's appetite for this, I'm happy to build it out.

[m13v]

the provider field (granola|fathom|none) closes this exact choice, but /process-meetings still branches on the provider name, so provider #3 forks the same conditional again. the boundary the switch doesn't touch is the shape of what comes back: fathom's transcript payload and granola's note structure don't normalize to one record, and onboarding has to fork per provider too. a thin adapter mapping each backend onto one meeting schema is what stops the drift, the config field just picks which adapter runs.