Ship a labelled QUESTION_TYPES catalogue from the package root

[jstet]

The published package exposes only mapping facts — kind, limeSurveyType, supported, requiresListName, answerClass, dateFormat — via TYPE_MAPPINGS. The human-facing fields (skos:prefLabel, useWhen, the variant → base relation, constraints) exist in registry/entities/<type>/definition.jsonld and are rendered into the generated skill reference and the docs site, but nothing exports them as data. Because the package's files field is ["dist"], the registry itself never reaches a consumer's node_modules, so the data isn't reachable any other way either.

What this blocks

Two consumers hit this same wall:

• CorrelAid/qwac#11 — the type-tag and preview UI needs display labels and the "use when" guidance to render a question picker. Right now it would have to hardcode or guess them.
• CorrelAid/formulaid#12 — #11 derives its QuestionType union from mapping facts (see src/lib/agents/types.ts:1 and the comment in the handover) precisely because the labels aren't reachable as data. Any future UI text naming a type has the same problem.

One upstream change serves both repos.

Proposed shape

Add an emitter step to codegen/emit_ts.py (or a new emitter) that reads the same registry sources already used for TYPE_MAPPINGS and produces a richer, derived catalogue. Export it from the package root:

export interface QuestionTypeEntry {
  /** registry @id, e.g. "type:select_one" or "variant:select_one_other" */
  id: string;
  /** the XLSForm `type` string for this row, e.g. "select_one" */
  typeString: string;
  /** human label, sourced from skos:prefLabel */
  label: string;
  /** methodology guidance, sourced from useWhen */
  useWhen: string;
  /** "question" for authored rows, "metadata" for start/end/today/etc., "structural" for begin/end_group */
  kind: 'question' | 'metadata' | 'structural';
  /** for variants and composites: the base type this derives from */
  base?: string;
  isVariant: boolean;
  isComposite: boolean;
}
export const QUESTION_TYPES: Record<string, QuestionTypeEntry>;

This is derived data — every field is already in the registry, so the change is emitter + index export, not a registry change.

Acceptance criteria

• QUESTION_TYPES is exported from dist/index.js with a .d.ts entry alongside (already emitted since e7842ed)
• Every entry has label, useWhen, kind, isVariant, isComposite populated
• Variants carry the right base reference (e.g. select_one_other.base === "select_one")
• Metadata rows (start, end, today, deviceid, username, hidden, audit) are present with kind: "metadata"
• Documented in README.md as the public API for "what types exist"
• A test pins the count and asserts each base type has at least one variant where the registry defines one (catches accidental drops)

Suggested validation gate

Run the existing snapshot suite (npm run bless) and the unit tests. If a fixture referencing TYPE_MAPPINGS moves, the new export is the consumer-visible source of truth and the old mapping should be re-derived from it (or at least, the diff should be reviewed to confirm it is the intended change).