Migrate Gmail secrets into credentials

## Original requirement (verbatim, epic 13348) Deep research all third party integrations in Lovable (Connect) and implement all of them. Ensure the highest level of code reuse, abstract out any generic code across all integrations. Users need an easy way to connect. Documentation must be as detailed as in Lovable or better. If something needs to be done on the partner website (e.g. register an app) and it can only be done by human create a follow up task per third party with exact step by step of what user needs to do). Mark it as user only task to set up but the runner will validate it was done correctly. You can refactor anything to make working with creds more robust. ## Settled inputs Full PRD and architecture: the epic's `prd` and `architecture` artifacts (Task 13348 BA, Task 13349 Architect). Section numbers below (§3.2 item 6, AC2.3, …) refer to them. They are settled: realize them, do not reopen them. Operator decisions O1–O6 and D1–D8 bind. ## This child's scope C8, architecture §6 Gmail row, release N only (the column drop is the final retirement child). Same two-release pattern as Slack. - Credential types `gmail_oauth` (refresh token; provider `gmail`, platform app, `client_source = platform`) and `gmail_service_account` (JSON key), both `system_owned`. - `gmail_connections.credential_id` already exists from C1's revision (no migration in this child). `gmail_connections` keeps the address, `can_receive`, history cursor and errors. - `legacy_adopt.py::adopt_gmail`: idempotent re-seal from `gmail_connections.sealed_secret`, counts to the system-activity record, unopenable rows → needs_reconnect with reason. - Readers in `apps/api/app/tenant_gmail/` prefer the credential, fall back to `sealed_secret`. - Gmail connect runs on the shared engine via `OAuthProvider.on_grant = tenant_gmail.on_grant`. - Callback compatibility: the redirect URI already registered at the vendor for this flow must keep working (route it into the shared callback handler) so the move needs NO partner-site change; if a vendor-side change is unavoidable, say so in the PR and report so a human setup task can be filed. - The secret still never reaches a node (`models/tenant_email.py` docstring stays true). Security surface: autonomous security review lane. Credentials & reach: - C19 precondition (legacy re-seal complete): the operator console's system-activity record via `org/console/dev-login` on app.dev.jaah.ai — verified reach; the record itself is created by C7 and C8 - Unit tests, `./dc check quick`, `tools/check_context.py` — verified (no credential) Out of scope (PRD §6, verbatim, plus what NOT to touch): - No app-user connectors (per-end-user OAuth, connector gateway for published apps). - No "Managed by Jaah" vendor keys or credit billing; no change to `apps/api/app/billing/`. - No per-vendor API client libraries or MCP tool wrappers built by Jaah (except where the vendor's own hosted MCP server is the connector). - No Lovable action-approval UI (allow once/always). - No change to runner auth to model providers (`account_auth.py`, `Account` table) or to login/sign-in OAuth (`routes/login_oauth.py`). - No change to NodeVault crypto semantics (`credential_crypto.py` encryption tiers) beyond what a refactor needs to keep behaviour identical. - Do not break existing rows: every existing credential type and every existing row keeps working; migrations additive (two-release overlap rule). - Supabase/project-backend and git-sync are not new work; Figma plugin/.fig upload out. - Never write a credential value into a task, doc, log or PR. - Do NOT file Tasks (no licence): the human-only OAuth registration tasks are filed outside this child. - Do NOT drop `sealed_secret` here (release N+1, the retirement child). Done means: - AC1.3 (Gmail) The Gmail credential-filling connect path runs on the shared engine. — `grep` for Gmail authorize/exchange code outside the shared engine + its `on_grant` hook returns nothing; unit test drives a Gmail connect through the shared start/callback. - No-break: an existing tenant Gmail connection keeps sending/receiving — unit test: pre-migration OAuth and service-account rows are adopted, readers return the same secret via the credential, second run is a no-op, unopenable row → needs_reconnect and counted. - Counts in the system-activity record — unit test. - `credential_get` on a migrated Gmail row returns 404 — unit test. - After deploy to dev, the system-activity record shows pending = 0 — cited in the report (the retirement child's precondition). - AC1.5 `./dc check quick` green and `tools/check_context.py` green on this PR — the gate output cited in the PR body.