Add chart-discriminated Vega-Lite authoring types

[Alper Sarikaya (yelper)]

This is a PR only to concretize the acceptable chartProperties options available to individual chart types. This is needed because ChartAssemblyInput accepts arbitrary chart names and properties, so TypeScript cannot catch misspelled options or properties used with the wrong chart.

What did you do?

Add opt-in VegaLiteChartType, VegaLiteChartPropertiesMap, and VegaLiteChartSpec exports generated from the live registry. Preserve native fields and runtime compatibility, with build integration, drift checks, consuming TypeScript fixtures, and authoring documentation.

Changes

Add three opt-in, type-only exports from flint-chart and flint-chart/vegalite:

• VegaLiteChartType: names from the live Vega-Lite registry.
• VegaLiteChartPropertiesMap: chart-specific property shapes derived from template properties and encoding-action controls.
• VegaLiteChartSpec: a chart-discriminated union for authoring with satisfies, preserving native titles, sizes, and encodings.

The types preserve literal option values, registered tuples, and explicit undefined defaults. They include the supported facetColumns and deprecated showTextLabels inputs while excluding data-dependent transition IDs. Existing ChartAssemblyInput, runtime signatures, and assembly behavior remain unchanged.

Build integration

The generated types are checked into source control. npm run gen:chart-types -w packages/flint-js regenerates them directly from the source registry using an in-memory esbuild bundle, so generation does not depend on an existing dist build.

The package build runs generation before tsup emits JavaScript and declarations. CI checks generated-file drift before building, preventing regeneration from masking stale checked-in output. After building, a dedicated TypeScript project checks the public package entrypoints with skipLibCheck: false and exactOptionalPropertyTypes: true; this check also runs before publishing.

Why did you do it this way?

An alternative approach is to generate a schema (maybe JSON), but this isn't naturally consumed by downstream consumers and tool builders.