Gmail OAuth2 login for PQ email retrieval

[AgreeDK]

Problem Statement

#443 implements PQ-from-email using generic IMAP + app-password, which
already works for Gmail (2FA + app-password). However, app-passwords are
an extra manual setup step for users, and some users may not want to
enable 2FA just to generate one.

Proposed Solution

Add Gmail as an OAuth2 login option alongside the generic IMAP path from
#443, so Gmail users can just click "Connect with Google" instead of
generating an app-password.

• Use google-auth / google-api-python-client (official SDKs) rather
  than hand-rolled OAuth, to stay on the maintained side of any future
  protocol changes
• Local loopback browser flow (opens system browser, listens on
  localhost callback) — standard pattern for desktop OAuth apps
• Request the minimal scope needed: gmail.readonly
• Token storage/refresh via keyring, same credential store as Get PQ from e-mail account #443
• Implements the shared EmailProvider interface from Get PQ from e-mail account #443
  (GmailOAuthProvider), so it plugs into the same fetch/parse/DB-match
  pipeline without changes there

Notes / constraints

• gmail.readonly is a restricted Google OAuth scope, requiring
  Google's app verification process before general release. Since
  OpenSAK is a pure desktop app with no backend server, we should be
  exempt from the costly annual security assessment — but standard
  verification (brand review + scope review) still applies and can take
  from a few days to a few weeks. Start this process early, in
  parallel with development — it's an external dependency, not dev
  time, and shouldn't block the rest of the implementation.
• Until verification completes, users will see Google's "unverified
  app" warning on first login — worth a short note in the UI/user guide
  so it doesn't look like a bug or a security problem with OpenSAK.
• Expect roughly one maintenance session per year as Google updates
  OAuth/API requirements (this has happened before and will again) —
  a standing cost of third-party OAuth integration.
• This is a convenience layer, not a functional requirement — Get PQ from e-mail account #443's
  IMAP+app-password path already covers Gmail if this gets deprioritized.

Depends on

• Get PQ from e-mail account #443 (EmailProvider interface, fetch/parse/DB-match pipeline)

Expected Benefits

Smoother login UX for Gmail users — no manual app-password setup.

[AgreeDK]

Putting this on hold along with #443 — this issue only existed to give #443
a smoother login than a plain app-password (Gmail already works fine via the
existing generic IMAP + app-password path from #443's first session). With
#443 paused (see comment there for why — Geocaching.com's PQ e-mails haven't
included the actual zip attachment since 2014, only a login-required
download link), there's nothing left for this to improve on right now.

Will revisit alongside #443 if/when Partner API access changes the picture.