FEAT: native Gmail REST API backend (alongside imap/jmap/pop3)

[mvanhorn]

Is your feature request related to a problem?

The Gmail OAuth path that landed in #415 is great, but it's still IMAP+XOAUTH2 underneath. That means matcha keeps using IMAP's folder/mailbox model when Gmail is fundamentally label-based, depends on the user keeping IMAP enabled (which Workspace admins can disable), and uses IMAP IDLE for push instead of Gmail's native signals. A few open issues read like symptoms of forcing Gmail's data model through IMAP: #1137 (labels), #509 / #638 / #1130 (threading), #1166 (connection pool), #1169 (UIDVALIDITY).

Describe the solution you'd like

A new backend/gmail/ Provider that talks to Gmail's REST API (google.golang.org/api/gmail/v1) and registers as Protocol: gmail alongside the existing imap, jmap, pop3. The shape mirrors backend/jmap/jmap.go exactly: same init() registration, same string-ID-to-uint32 hashing pattern. Reuses the existing OAuth scaffolding in config/oauth.go and oauth_script.py; the Python helper picks up an --api-mode flag that adds the gmail.modify scope for gmail-protocol accounts and leaves IMAP+OAuth accounts on mail.google.com unchanged.

Send goes through users.messages.send with raw RFC 822, so PGP-signed/encrypted mail flows through the existing composition pipeline byte-for-byte. Watch starts as History API polling; Pub/Sub is a follow-up.

This is additive. The IMAP backend is unchanged. Users who keep Protocol: imap see no difference. The split exists because Workspace policies, IMAP-disabled accounts, and the data-model gap are real for some users but not all.

Describe alternatives you've considered

• Replacing the IMAP backend's Gmail handling in-place. Larger blast radius, breaks the principle that Protocol selects backend.
• Synthesizing IMAP responses from Gmail API calls under the existing backend. Higher implementation cost, no architectural benefit.
• Doing nothing and letting FEAT: Implement proper OAuth2 token refresh flow #635 / FEAT: Add automatic OAuth2 token refresh #782 (OAuth refresh refactor) carry the OAuth-on-IMAP path forward. That's the right path for users who pick IMAP. This proposal is for the users who'd rather not.

Additional context

Pre-flight question before writing code: would this be welcome as a new backend, or would you rather see this energy go into the existing OAuth-IMAP path (#635 / #782)?

If welcome, I have a phased delivery in mind:

• Phase 1 (read-only): list + fetch + search + scope additions. ~300-400 LOC. Lets the architecture be evaluated without committing to send-path correctness.
• Phase 2 (write + send): label modify, batch modify, raw send. ~250-350 LOC.
• Phase 3 (watch): History API polling MVP. ~150 LOC. Pub/Sub is its own follow-up.

Affected packages: new backend/gmail/; small additive changes to tui/login.go, config/oauth_script.py, config/config.go; new docs/docs/setup-guides/gmail-native.md. No changes to backend/imap/, backend/jmap/, backend/pop3/, PGP, or the composition pipeline.

Happy to skip this if it conflicts with where you want the OAuth area to go.