fix(erd): PostgreSQL catalog misses keys for non-owner roles, composite FKs give wrong edges; read pg_catalog #1167

Problem

ErdCatalog reads PostgreSQL through information_schema (erd_catalog.dart). Three problems:

• Read-only roles see no keys. Per the PostgreSQL docs, information_schema.table_constraints lists only constraints of tables the current user owns or has some privilege other than SELECT on, and constraint_column_usage only columns of tables owned by a currently enabled role. Connected as an application or read-only user (not the schema owner), the diagram shows tables without PK markers and without relations.
• Composite foreign keys produce wrong edges. The FK query joins key_column_usage and constraint_column_usage on the constraint name only; for a 2-column FK (a, b) → (x, y) this yields 4 pairs (a→x, a→y, b→x, b→y) instead of 2.
• Slow on large catalogs. information_schema views are much slower than pg_catalog on databases with thousands of tables.

Scope

• Columns: pg_attribute + pg_class + pg_namespace (attnum > 0, not dropped, relkind IN ('r','p')), type via format_type, PK via pg_index / pg_constraint contype = 'p', nullability via attnotnull (useful for feat(erd): nullability, optional/mandatory edge ends, edge tooltip #1156).
• Foreign keys: pg_constraint contype = 'f' with unnest(conkey, confkey) WITH ORDINALITY, so composite keys pair column by column; referenced table with its schema (cross-schema FKs, refactor(erd): ErdSource per connection, schema-aware catalog, neighbourhood load #1147).
• Keep aliases distinct (the SQLite map caveat in the class comment).
• Check MySQL for the same composite-key behaviour (key_column_usage has one row per column pair there, expected correct) and add a test.

Acceptance

• A role with only SELECT on the tables sees PKs and FKs.
• A composite FK draws 2 edges between the right columns.
• Catalog tests: composite FK, cross-schema FK, non-owner role (SQL-level test with recorded rows).