[alvaroderas]

Which problem is this PR solving?

Addresses TASK-387311: Turn makenotion/refinery into refinery type source of truth

This PR makes makenotion/refinery the source of truth for TypeScript configuration types, enabling a future typed config generator in notion-next. It builds on the approach proposed in this closed PR.

Reviewer note: config-types/index.d.ts is generated from Refinery’s metadata and accounts for most of the diff. Focus review on the generator, tests, and package setup; the declarations can be spot-checked rather than reviewed line by line. CI verifies that the generated output is up to date.

Short description of the changes

• Adds the private & types-only package @notionhq/refinery-config-types, exporting generated configuration, sampling-rule, and sampler types.
• Generates declarations directly from config/metadata/configMeta.yaml and rulesMeta.yaml, including field documentation and defaults.
• Enforces required fields, allowed values, mutually exclusive fields, and exactly one sampler per target.
• Adds compilation tests and CI checks that reject stale generated declarations.
• Documents regeneration and package consumption during future Refinery upgrades
• Restricts the inherited Honeycomb labeling workflow to the upstream repository, preventing failures in the Notion fork.

How was this tested?

• npm test passes, including generated-file freshness checks, valid/invalid TypeScript configuration examples, and seven generator regression tests.
• Confirmed the regression tests fail when the corresponding generator behavior is deliberately broken.
• Confirmed the freshness check fails when generated declarations are modified.
• Packed and installed the package in an isolated consumer, then compiled imports without build hooks.
• Verified the package against the existing notion-next Refinery configurations.

There are no runtime or deployment configuration changes. A follow-up PR in notion-next will officially add the dependency and typed configuration generator.