Add opt-in schema-scoped PostgreSQL introspection

[Zetazzz]

What this changes

PostgreSQL introspection currently reads the full catalog even when a service
exposes only a small set of schemas. On databases with large catalogs, most of
that work and result data is unrelated to the generated GraphQL schema.

This PR adds opt-in schema-scoped introspection. It starts from the schemas in
pgService.schemas, recursively retains the catalog objects needed by those
schemas, and validates the result against the same plan that built the query.

When scoped introspection is omitted or disabled, the service uses the existing
stock query. The stock SQL and the existing parse, cache, watch, registry, and
entity-event lifecycles remain unchanged.

This PR and #3 use the same pg-introspection query-plan API and scoped
algorithm. This PR integrates the feature directly into
PgIntrospectionPlugin; #3 is the hook-based alternative. Only one of the two
PRs should merge.

Configuration

No additional plugin or preset is required. Configuration is keyed by the
name of an existing entry in pgServices.

The preset below is abbreviated: mainPgService and
analyticsPgService represent the existing connection, adaptor, and other
service settings.

const preset: GraphileConfig.Preset = {
  pgServices: [
    {
      ...mainPgService,
      name: "main",
      schemas: ["app_public"],
    },
    {
      ...analyticsPgService,
      name: "analytics",
      schemas: ["analytics"],
    },
  ],

  gather: {
    pgScopedIntrospection: {
      // Matches pgServices[0].name.
      main: true,

      // Matches pgServices[1].name.
      analytics: {
        catalogTypes: "dependency-closure",
        capabilityExtensions: ["pg_trgm"],
      },
    },
  },
};

The keys main and analytics are not fixed names or schema names. Each
key must match a pgServices[].name. The matching service's schemas
array supplies the scoped root schemas, so schemas are not repeated inside
pgScopedIntrospection.

Service value	Behaviour
omitted	Use stock introspection
false	Use stock introspection
true	Use scoped introspection with defaults
object	Use scoped introspection with the supplied options

Services omitted from pgScopedIntrospection continue to use stock
introspection.

Options

interface SchemaScopedIntrospectionOptions {
  catalogTypes?: "all" | "dependency-closure";
  capabilityExtensions?: readonly string[];
}

• catalogTypes: "all" is the default. It retains types required by the
  dependency closure plus all types in pg_catalog. This is the more
  conservative compatibility setting.
• catalogTypes: "dependency-closure" retains only types reachable from the
  scoped roots and their dependencies.
• capabilityExtensions explicitly retains extension metadata even when no
  retained object currently depends on that extension. It retains the
  extension record, not every object owned by the extension.

Extensions required by retained tables, indexes, functions, or support objects
are discovered automatically. They do not need to be repeated in
capabilityExtensions.

Schema and dependency behaviour

• root schemas come only from pgService.schemas
• referenced relations, constraints, function signatures, domains, arrays,
  ranges, multiranges, indexes, inheritance parents, and extension metadata
  enter the dependency closure automatically
• dependencies may cross schema boundaries when a retained object requires
  them
• there is no dependency-schema allowlist
• unrelated schemas and catalog objects are not retained merely because they
  have similar names or belong to the same extension

Fail-fast behaviour

• configuring an unknown PostgreSQL service name fails
• enabling scoped introspection for a service without root schemas fails
• a missing configured root schema fails after the result is parsed
• missing dependency types and dangling type references fail validation

Ownership and execution flow

Concern	Owner
Scoped SQL, CTEs, and parameters	pg-introspection
Normalized scope and query plan	pg-introspection
Result integrity validation	pg-introspection
Service configuration and lifecycle	graphile-build-pg
Query execution and service context	graphile-build-pg

graphile-build-pg has no separate scoped-introspection adapter module. The
remaining Graphile-specific logic lives directly in PgIntrospectionPlugin:

read service configuration
  -> select stock query or scoped plan
  -> execute query
  -> parse introspection
  -> validate the scoped result with the same plan
  -> emit the existing entity events

The benefit is a direct integration with no new plugin or hook contract. The
trade-off, and the main review question for this PR, is that the stock plugin
becomes aware of scoped configuration and query selection.

Compatibility and safety

• makeIntrospectionQuery() retains its existing public behaviour and exact
  generated SQL; a golden test protects it
• scoped introspection is opt-in per service
• dependency schemas are discovered rather than configured
• validation uses the normalized scope carried by the executed query plan
• no default behaviour, preset, lockfile, parse lifecycle, cache, watch, or
  entity-event behaviour changes

Validation

• pg-introspection: build passed; 46/46 tests passed
• owner tests cover plan normalization, missing roots, missing function types,
  dangling column types, and types retained in internal lookups
• graphile-build-pg: build passed; 23/23 tests passed
• configuration tests exercise the real gather/plugin path
• real PostgreSQL integration verifies stock/scoped schema equivalence, runtime
  execution, cross-schema types and functions, ranges and multiranges, foreign
  keys, inheritance, ordinary indexes, and pg_trgm GIN/GiST indexes
• affected ESLint and Prettier checks passed
• git diff --check passed; no format-only changes