Connector seed migrations' downgrade() lacks a provenance guard on the public_mcp_apps row

[yiboyasss]

Context

Found and fixed for Salesforce's own seed migration while addressing PR #1459 review feedback (commit range up to 2eac27d). The same template is used by other connectors' seed migrations and has the identical gap.

The bug

Each connector's seed migration (src/xagent/migrations/versions/*_seed_*_mcp_app.py) follows this pattern in downgrade():

if "public_mcp_apps" in existing_tables:
    bind.execute(
        sa.delete(PUBLIC_MCP_APPS_TABLE).where(PUBLIC_MCP_APPS_TABLE.c.app_id == APP_ID)
    )

This deletes the row unconditionally by app_id, with no check that the row actually matches the shape this migration seeded -- unlike the matching oauth_providers deletion further down, which does guard on the seeded row's stable fields (name/auth_url/token_url) specifically so an admin-created provider row survives a downgrade.

Concretely: upgrade() skips inserting when app_id already exists (so a pre-existing operator row is left alone), but downgrade() doesn't check the same thing before deleting -- it just deletes whatever currently has that app_id, whether or not this migration is the one that put it there. Two consequences:

1. A pre-existing operator row that happened to already occupy that app_id before the migration ever ran gets deleted on downgrade even though upgrade() never touched it.
2. That deletion can then make the "any apps still using this provider?" count (used to decide whether to also delete the oauth_providers row) read as zero, letting the provider row get deleted too.

What was fixed

src/xagent/migrations/versions/20260818_seed_salesforce_mcp_app.py's downgrade() now guards the public_mcp_apps deletion the same way the oauth_providers deletion already was (match on name/transport/provider_name, all stable and non-env-dependent).

Where this pattern likely still exists

At minimum confirmed in src/xagent/migrations/versions/20260818_seed_jira_mcp_app.py's downgrade(), same shape. Likely present in every other connector's seed migration that follows this template (zoom, intercom, slack, chrome, hubspot/docs/slides, etc.) -- worth an audit pass across all of them rather than patching one at a time, since this is a template-level gap, not connector-specific logic.

Not fixed for jira or the others as part of #1459 since those migrations belong to different, already-merged connectors this PR doesn't otherwise touch.

[yiboyasss]

Two updates from continued review on #1459:

Confirmed full list of affected migrations (same gap, verified this round): 20260818_seed_jira_mcp_app.py, 20260818_seed_linear_mcp_app.py, 20260812_seed_intercom_mcp_app.py, 20260730_seed_zoom_mcp_app.py, 20260720_seed_docs_slides_hubspot.py, 20260806_seed_chrome_mcp_app.py, 20260807_seed_notion_mcp_app.py, 20260806_seed_google_sheets_mcp_app.py, 20260731_seed_aws_mcp_app.py, 20260731_seed_granola_mcp_app.py, 20260730_seed_google_analytics_mcp_app.py, 20260724_seed_google_ads_mcp_app.py, 20260703_seed_google_maps_mcp_app.py. Several of these (notion, google_sheets, aws, granola, google_analytics, google_ads, google_maps) have it worse than jira did originally -- zero shape guard at all on the public_mcp_apps delete, not even the narrow structural-columns check salesforce started with.

Important implementation pitfall for whoever fixes this: salesforce's own guard was first strengthened to match every non-env-dependent column (oauth_scopes/launch_config/default_scopes included) via SQL .where(json_column == python_value) -- this compiles fine but is actually broken on PostgreSQL, which has no = operator for its plain json column type (only jsonb does; these columns are declared as plain JSON in the models, not .with_variant(JSONB(), "postgresql")). It would raise UndefinedFunction: operator does not exist: json = json the first time alembic downgrade ran on a Postgres-backed deployment, silently un-caught by the test suite since it only exercises SQLite. Fixed by fetching the row with a plain SELECT (filtered only by the string lookup key, e.g. app_id) and comparing every field -- JSON columns included -- in Python, then issuing the DELETE by that same safe string key. Whatever fix lands for the other connectors listed above should use that fetch-then-compare-in-Python shape rather than pushing JSON-column comparisons into the SQL WHERE clause.