Connector deletes take 3-7 s: kg_edges has no index on its node columns #1638

Deleting a connector cascades to its kg_nodes, and each deleted node makes Postgres look up kg_edges by source_node_id and by target_node_id. Neither column has an index of its own (only the unique (organization_id, source_node_id, target_node_id, kind)), so every node costs two full scans of kg_edges (about 261k rows, 55 MB, 40-100 ms each).

Seen on Cloud: DELETE /api/connectors/:id takes 3 to 7.6 s, and the Instagram path, which deletes inside one transaction, hit the 5 s transaction timeout (Sentry ANYTHINGMCP-CLOUD-BACKEND-4, connector with 30 graph nodes).

Fix: add @@index([sourceNodeId]) and @@index([targetNodeId]) on KgEdge, built with CREATE INDEX CONCURRENTLY so the table is not locked during the release overlap.