feat: add json generator exposing the raw generator metadata

[spydon]

Important

Duplicate of the postgrest-typegen extraction: the GeneratorMetadata contract in supabase/pg-toolbelt#302 is the same language-neutral document this PR exposes, and #1084 makes postgres-meta consume that package. The json output is reimplemented on top of the package in #1110, stacked on #1084. Closed in favor of that stack.

What kind of change does this PR introduce?

Feature: a new json generator alongside the existing typescript, go, swift, and python ones.

What is the current behavior?

The introspection metadata that all type generators consume (GeneratorMetadata: schemas, tables, foreign tables, views, materialized views, columns, relationships, functions, and types) is only available rendered through one of the four built-in language templates. Anyone building a type generator for another language (Dart, Kotlin, C#, and the various community SDKs) has to fall back on lossier sources such as the PostgREST OpenAPI description, which for example cannot distinguish a nullable column from a NOT NULL column with a database default.

What is the new behavior?

• GET /generators/json returns the raw GeneratorMetadata as pretty-printed JSON, supporting the same included_schemas/excluded_schemas query parameters as the other generators.
• PG_META_GENERATE_TYPES=json (and the gen:types:json npm script) emits the same document on stdout, so the Supabase CLI can expose it as supabase gen types --lang json and --lang dart (feat(gen): add dart and json output languages to gen types cli#6230).
• The document carries a top-level version field (currently 1) so external consumers can detect breaking shape changes; additive changes do not require a bump.

This gives third-party and community type generators a single high-fidelity, language-neutral introspection source instead of each reimplementing catalog queries or parsing lossy API descriptions.

Additional context

The template is a stable-key-order JSON.stringify over the existing getGeneratorMetadata result, so it adds no new queries and stays in sync with whatever the built-in generators see. Tests assert the envelope shape and specifically the fidelity data that motivated the endpoint (nullability, defaults, identity columns, enum values, views, materialized views, and function return types).

Why a JSON dump instead of a Dart template in this repo?

The concrete first consumer is the upcoming Dart type generator for supabase-flutter (supabase/supabase-flutter#1635). We deliberately chose not to contribute a dart.ts template here, for reasons that apply equally to any future language:

• The generated code targets a client API that lives in the SDK repo. The Dart output is not standalone model classes; it emits table definitions, column tokens, and extension types that implement a contract the supabase-flutter client expects. That surface and the generator have to change in lockstep, which is only practical when both live in the same repository and can land atomically in one PR. A template here would be maintained at arm's length from the API it generates against, on a different release cadence.
• This repo cannot verify the output. The existing templates emit source as strings into a CI that has no Dart toolchain. In the SDK repo the generated code is compiled, linted, and run against the actual client in behavior tests.
• It keeps the review burden where the expertise is. Maintainers here should not have to review idiomatic Dart, and SDK maintainers should not have to reimplement catalog introspection.

The JSON generator is the piece that genuinely belongs here: the introspection metadata is postgres-meta's domain, every language needs the same document, and one endpoint serves Dart, Kotlin, C#, and the community SDKs alike without this repo taking on a template per language.