Testing: verify ALTER EXTENSION UPDATE yields a DB equivalent to a fresh install

[jnasbyupgrade]

Problem

PR #16 (0.3.0) shipped two bugs in the 0.2.2→0.3.0 update path that our
testing did not catch:

1. A semantically backwards relkind mapping (c/f/m → composite
   type / foreign table / materialized view were swapped) — present in both
   the fresh-install script and the update script.
2. A missing REVOKE EXECUTE ... FROM PUBLIC on _cat_tools helpers in the
   update script, leaving updated databases with broader ACLs than fresh
   installs of the same release.

Why current testing missed them

• test/build/upgrade.sql (local, runs under make test) only does
  BEGIN; CREATE EXTENSION '0.2.2'; ALTER EXTENSION UPDATE; ROLLBACK; with
  output suppressed. It is a "does the script execute" sanity check — no
  assertions, no comparison to a fresh install.
• The CI extension-update-test job does run the full make test suite
  against the updated DB, but:
  • it never compares the updated DB against a fresh-install DB, so the
    missing REVOKE (identical version number, different ACL) is invisible;
  • the relation__ mapping test is tautological: it derives its expected
    values from a positional zip of the two enums, and the mapping function was
    written to agree with that same zip — so a uniformly-wrong-but-internally-
    consistent mapping passes. (Fixed separately in PR Add new functions, enums #16; see the temp-view
    approach there.)

Idea 1 — fresh-vs-updated catalog equivalence check

Build two databases:

• fresh: CREATE EXTENSION cat_tools (current version)
• updated: CREATE EXTENSION cat_tools VERSION '<oldest updatable>' +
  ALTER EXTENSION UPDATE

Then diff normalized catalog state for extension-owned objects and fail on any
difference. At minimum compare pg_proc (prosrc, proacl, provolatile,
proargtypes, prorettype, proconfig), plus pg_type/enum labels and
pg_description.

Note: pg_dump cannot be used for this — it does not emit the definitions
of extension-owned objects (only the CREATE EXTENSION line). The comparison
must query the catalogs directly.

Idea 2 — local update-then-test mode

We have CI coverage that runs the suite post-update, but no equivalent local
mode. Add a make target / test mode that installs the oldest updatable
version, runs ALTER EXTENSION UPDATE, and then runs the full pgTAP suite
against the updated database — mirroring the CI extension-update-test job
locally so divergences are caught before push.

pgxntool now has test/install (static install) support that may provide the
scaffolding for this.

Scope

Deliberately split out of PR #16 (already large). Either idea alone would have
caught at least one of the two bugs above.