feat(postgres): browse multiple databases on one connection

[debba]

Closes #340.

What this does

You can now point a single PostgreSQL connection at several databases and browse them all from the sidebar, the same way MySQL and MariaDB connections already work. Pick the databases you want in the connection dialog's "Databases" tab and each one shows up as a top level node you can expand into its schemas and tables.

Why Postgres needed special handling

MySQL lets one connection see every database, so the old multi database code treated a database name as if it were a schema and qualified table names with it. Postgres does not allow that: a connection is bound to one database and you cannot query across databases in a single session. So this PR keeps a separate connection pool per database and presents a real database to schema to table tree instead of the flat database to table layout MySQL uses.

The pool keying already included the database name, so most of the plumbing was about telling the backend which database a given read or query should run against.

How it works

• Metadata reads (get_tables, get_views, get_schemas, get_columns, get_indexes, get_foreign_keys, the routine and trigger helpers) and execute_query / execute_query_batch now take an optional database argument. When set, the params get pointed at that database and the matching pool is used. This mirrors the convention the record mutation commands (delete_record, update_record, insert_record) already follow, so it is purely additive.
• Editor tabs carry the target database alongside the schema, so previews, queries and row edits route to the correct pool while still qualifying tables with the Postgres schema.
• isMultiDatabaseCapable no longer excludes schema based drivers; a new isSchemaBasedMultiDb helper distinguishes the hierarchical Postgres layout from the flat MySQL one.
• Empty database selections fall back to the postgres maintenance database, since Postgres cannot connect without a target. This is what makes "Load Databases" work before you have picked anything.

UX change worth a look

Now that PostgreSQL counts as multi database capable, the connection dialog hides the single "database" field on the General tab and shows the "Databases" tab with a checklist instead, exactly like MySQL. Existing single database Postgres connections keep working, but the edit dialog looks different than before. Happy to keep the single field visible for Postgres if reviewers would rather not change that flow.

Known limitations / follow ups

These are not regressions, just things left out of this pass to keep the change focused on browsing and querying:

• Object-creation DDL from the nested schema view is not database aware. Create Index, Create Foreign Key and Create Table / View / Trigger launched from a nested Postgres schema node still route via the connection's global active schema and carry no database, so they can hit the primary database (and the wrong schema). Add/edit column, drop index and drop foreign key are routed to the node's database in this PR.
• SQL autocomplete is not database aware in multi-database mode. registerSqlAutocomplete / getTableColumns take a schema but no database, so get_columns runs against the connection's primary pool — completions for tables in a non-primary database are missing or wrong. It still assumes the flat MySQL shape.
• Per-database dumps route to the correct database but scope schema via the global active schema. dump_database is bound to the selected database's pool (Postgres now counts as multi-database capable), but the schema it receives is the connection-wide active schema, so a dump taken while a different schema is active may be scoped incorrectly.
• Sidebar highlight and auto-expand reuse activeSchema for both the database node and the schema node, so the highlight can be slightly off. Navigation works fine.
• No cap or idle eviction on the per-database pools yet. Each selected database keeps its own pool (max 10 connections) for the lifetime of the connection; pools are released only on explicit disconnect.

Testing

• New unit tests for the postgres_dbname fallback helper and for the isMultiDatabaseCapable / isSchemaBasedMultiDb changes.
• Full suites pass locally: 753 Rust tests, 2705 frontend tests, plus tsc and ESLint clean.
• Still needs a manual pass against a real Postgres server with two or more databases selected.

[NewtTheWolf]

Reviewed locally (tests pass: frontend 140, backend pool_manager 36). The architecture is solid — per-database pool keying (postgres:conn:<id>:<db>), the postgres maintenance-db fallback is contained to connection params (never reaches SQL), and the multi-db logic is capability-driven (no driver === "postgres" conditionals). Nice.

The one real issue is that database threading is incomplete — three call paths still route to the connection's primary DB:

Blockers

• execute_query_batch (src-tauri/src/commands.rs:3172) never got the database param (only schema), so batch/multi-statement execution runs against the primary DB. execute_query does it right at commands.rs:3104 — mirror that.
• Export sends the schema as the database — src/pages/Editor.tsx:2704 uses activeTab?.schema as targetDatabase. For Postgres (now multi-db-capable) that routes to the wrong pool. Use the buildTableRoutingParams(...) helper the PR already added (it's used at 575/1959/2132, just not here).
• count_query has no database — frontend src/pages/Editor.tsx:1141 and backend src/commands.rs:3321 both lack it, so pagination totals run against the primary DB → wrong count or error for non-primary databases.

Nits

• delete_record/update_record/insert_record (commands.rs:2761, :2792, :3045) use if let Some(db) = database without the .filter(|d| !d.is_empty()) guard the 13 read commands use — with the new maintenance-db fallback, a Some("") write lands on the postgres database.
• driver === "mysql" added at NewConnectionModal.tsx:1187 (pipes_as_concat) violates .rules/frontend.md no-driver-conditionals.
• The MySQL/SQLite pk_col → composite pk_map rework + added escape_identifier is a behavioural refactor riding along (.rules/rust.md Does not list databases, have to manually enter database name in connection window #6). Good change on its own (closes an identifier-injection vector, unit-tested) but ideally its own PR.

Repro for the three blockers, on a connection with multiple Postgres DBs selected: run a multi-statement query in a non-primary DB (B1), paginate a large table in a non-primary DB (B3 count), export a non-primary-DB table to CSV (B2) — each hits the primary pool instead.