setup/configure: infer --provider from mailbox email domain

[stevenobiajulu]

Observed

Running setup without --provider always defaults to microsoft, even when the --mailbox argument is an obvious Gmail address:

$ npx -y email-agent-mcp@0.1.6 setup --mailbox steven.obiajulu@gmail.com
[email-agent-mcp] Configuring mailbox "steven.obiajulu@gmail.com" with Microsoft Graph
[email-agent-mcp] Client ID: c4f91d3e-d2d9-4f8b-826f-6a3c19280241

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  To sign in, open this URL in your browser:
  https://login.microsoft.com/device
  Enter code: EH3KX5QBC
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The device-code URL sent the user to a Microsoft login screen for a Gmail address — confusing and wastes a round trip.

Expected

When --mailbox is an email address and --provider is not passed, infer the provider from the domain:

Domain suffix	Inferred provider
@gmail.com, @googlemail.com	gmail
@outlook.com, @hotmail.com, @live.com, @msn.com	microsoft
anything else (including custom business domains)	keep current default (microsoft), or prompt in TTY mode

Custom domains (e.g., @usejunior.com) can legitimately be on either provider, so falling back to the current microsoft default is fine for those — but the consumer free-tier suffixes are unambiguous and should not require the flag.

Where the code lives

packages/email-mcp/src/cli.ts — runConfigure() currently:

const provider = opts.provider ?? 'microsoft';

Replace the unconditional default with a small helper that checks the --mailbox suffix before falling back.

Additional thought

If TTY, could also interactively ask "Looks like a Gmail address — use the Gmail provider? [Y/n]" instead of silently inferring. Either works; inference with an override-via-flag is probably the least intrusive.

Severity / priority

Low — workaround is to pass --provider gmail explicitly. But it's a sharp-edge for first-time users and low-cost to fix.

Context

Discovered while setting up a Gmail mailbox immediately after v0.1.6 fixed the npx silent-exit bug (#39). Follow-up to that.