[bug] pg-meta: Cartesian product in FK relationship introspection produces incorrect cross-column pairings for composite keys

### Describe the bug When `@supabase/pg-meta` introspects foreign key constraints on tables using multi-column composite keys, it returns incorrect source/target column pairings. For a constraint such as: ```sql FOREIGN KEY (a, b) REFERENCES target(x, y) ``` the relationship metadata includes every possible combination of the source and target columns instead of preserving the positional mapping defined by the constraint. ### Reproduction ```sql CREATE TABLE public.ctgt ( x INT, y INT, PRIMARY KEY (x, y) ); CREATE TABLE public.csrc ( a INT, b INT, FOREIGN KEY (a, b) REFERENCES public.ctgt (x, y) ); ``` Then retrieve the table metadata: ```ts const table = await pgMeta.tables.retrieve({ schema: "public", name: "csrc", }) console.log(table.relationships) ``` ### Expected behavior The composite foreign key should preserve column order: ``` a -> x b -> y ``` Only these two relationships should be returned. ### Actual behavior The introspection returns four relationships: ``` a -> x a -> y b -> x b -> y ``` The two cross-column pairings are not part of the foreign key definition. ### Root cause The relationship introspection query joins source and target attributes independently using `ANY(conkey)` and `ANY(confkey)`. Since there is no condition matching the ordinal positions of entries in `pg_constraint.conkey` and `pg_constraint.confkey`, PostgreSQL produces the Cartesian product of the matching source and target columns for composite foreign keys. ### Impact - Incorrect relationship metadata for composite foreign keys. - Phantom edges in ERD/schema visualizations. - Downstream consumers relying on `pg-meta` relationships may infer invalid column mappings. I can open a PR with a fix if this approach looks correct.