Extension-owned type schema mismatch causes false-positive diffs (pgvector, etc.)

[ayusssmaan]

Bug

When a column's type is owned by a PostgreSQL extension (e.g. pgvector's vector), pgschema plan/diff can report a spurious ALTER COLUMN TYPE (or, for brand-new tables, fail outright at apply time) purely because the extension resolves to a different schema between the live database and the plan-time comparison environment.

Example: a table has chunk_vector domain.vector(384) on the real/live database (the vector extension is installed into schema domain), but in the ephemeral plan-time comparison database the extension happens to install into public instead (e.g. because that database's default extension-install path differs). The type is identical in every way that matters — only the schema qualifier differs — but pgschema's schema-qualifier comparison treats public.vector and domain.vector as different types and emits a diff.

A related issue: for a brand-new CREATE TABLE with an extension-owned column type, pgschema currently trusts whatever schema the plan-time environment resolved the extension to, with no live side to catch the discrepancy — this can produce CREATE TABLE DDL referencing a schema-qualified type that does not exist on the real target, failing with e.g. ERROR: type "public.vector" does not exist.

Impact

Any schema using an extension-owned type (pgvector, hstore, ltree, citext, etc.) installed in a non-default schema will see:

• Non-convergent plan/diff output (a diff that never resolves via apply), or
• Outright apply failures on first-time creation of tables with such columns.

Fix

Opening a PR that:

• Tracks the owning extension (if any) for columns, composite-type attributes, and domain base types via pg_depend/pg_extension.
• When both sides of a comparison are owned by the same extension, strips schema qualifiers before comparing — while still catching genuine changes (e.g. a vector dimension bump from vector(384) to vector(512)).
• Ordinary cross-schema types (domains, enums, contrib types installed at a fixed, deliberate location) are unaffected — only extension-owned types get this treatment.

Along the way, also found and fixed a related pre-existing bug where columns referencing (but not owning) another table's sequence were misclassified as SERIAL, causing non-idempotent apply runs and incorrect table creation ordering for shared sequences.

Referenced from PR (to be linked).