fix(mcp): MCP queries run on the user's read-only session; give MCP a session of its own #1217

Part of #1212.

Problem

The MCP server runs its queries on the user's own read-only session.

• createReadOnlyMcpDelegate (lib/core/mcp/mcp_sql_delegates.dart:11-30) builds the SQL editor's delegates with isReadOnly: true.
• For PostgreSQL that acquires PgSessionMode.readOnly (lib/features/postgresql/postgres_sql_workspace.dart:48) on row.databaseName ?? 'postgres': the same pool key as the tree catalog, stats dashboards and table browser of the default database. MySQL and SQLite delegates do the same with their readOnly mode.
• So an MCP client (Claude, an IDE agent) and the user share one TCP session per database:
  • MCP calls and UI calls wait for each other (one statement at a time per session).
  • An MCP timeout (15 s, lib/core/mcp/mcp_query_service.dart:44) force-closes the user's session (fix(db): a timeout or a server-side cancel force-closes a shared session, and a queued statement can cancel another caller's #1216).
  • An MCP statement waiting in line can cancel the statement the user is running (fix(db): a timeout or a server-side cancel force-closes a shared session, and a queued statement can cancel another caller's #1216).
  • Closing a table tab force-closes the session under an MCP call in flight (fix(db): closing a table tab force-closes the read-only session other views are using #1215).
  • Catalog tools (list_tables, describe_table, schema://) run the full column and FK catalog (up to 200 000 rows, mcp_query_service.dart:61) on that session on every call; the tree waits meanwhile.

MCP is not the root cause of the connection errors (they also happen with MCP off), but it adds an unattended client to the user's session and makes them more frequent and harder to explain.

Scope

• A session mode of its own for MCP per driver (PgSessionMode.mcp, MysqlSessionMode.mcp, SqliteSessionMode.mcp): read-only, own pool key, idle dispose like other slots.
• Server-side statement timeout on that session (SET statement_timeout / max_execution_time), so a runaway MCP query is stopped by the server and nothing is force-closed.
• Optional: cache the catalog per connection for a short time (or until the tree refreshes) so catalog tools do not rerun it on every call.
• The MCP log in Settings shows which session a call ran on (for support).

Acceptance

• Unit test: MCP delegates never acquire the pool key the UI uses (readOnly) for the same connection and database.
• Unit test (fake connections): an MCP query that times out leaves the UI's read-only session connected.
• Unit test: two MCP catalog calls within the cache window run the catalog once (if the cache is in scope).