fix(database): filter databaseDidConnect subscribers by payload connectionId

[datlechin]

Summary

Three subscribers to AppEvents.databaseDidConnect previously discarded the connectionId payload that the DatabaseDidConnect struct already carried, then ran connection-scoped work against their own connection regardless of which database actually connected. Fixed by guarding on payload.connectionId == self.connection.id (or the equivalent local target id):

• MainContentCommandActions.setupDatabaseBroadcastObservers (refreshTables per window)
• MainContentCoordinator plugin-driver retry sink (setupPluginDriver per window)
• ERDiagramViewModel.waitForConnection (continuation resumed by any signal)

Why this matters

This is bug R2 from the full-app audit, same shape as the mainCoordinatorTeardown event leakage that PR #1139 fixed. Reproduction:

• W1, W2, W3 each open a different connection (A, B, C). Open W4 with connection D.
• The databaseDidConnect for D fires. Without the filter, every existing window observes it and runs await coordinator.refreshTables() against its own driver: nine fetchTables() calls instead of one.
• For ER diagrams, waitForConnection resumed on any signal, then re-checked driver(for: connectionId) and failed with "No database connection" when the wrong DB connected first.

WelcomeRouter.drainPendingSQLFiles is intentionally connection-agnostic and TerminalTabContentView.waitForSSHTunnel re-checks state inside an AsyncStream body, so both are left unchanged.

Test plan

• Open three windows on three different DBs. Open a fourth. Confirm only the new window runs fetchTables() (Console: search for refreshTables / fetchTables log lines).
• Open an ER diagram for connection A while connection B is connecting. Confirm the diagram waits for A and does not transition to "No database connection" prematurely.
• swiftlint --strict clean.