`ComponentProperty` / `ComponentPropertyDefinition` should be split into type-specific schemas

[amotarao]

The current definitions of ComponentPropertyDefinition and ComponentProperty use a single flat schema with a type field referencing ComponentPropertyType, but mix type-specific fields (e.g. variantOptions, preferredValues, boundVariables) into one object with loose optionality.

This causes two concrete problems:

1. defaultValue / value have incorrect types. Both are defined as oneOf: [boolean, string], but the actual type is determined by the type discriminant — BOOLEAN should yield boolean, all others should yield string.
2. Type-specific required fields are not enforced. Fields like variantOptions (only meaningful for VARIANT), preferredValues (only meaningful for INSTANCE_SWAP), and boundVariables (only meaningful for VARIANT) are mixed into one schema. Code generators cannot determine which fields are required for which type, making generated types inaccurate.

Proposed Solution

Split each type into dedicated schemas using oneOf with a discriminator, similar to how other union types are modeled in this spec:

ComponentProperty

• BooleanComponentProperty (BOOLEAN, value: boolean)
• TextComponentProperty (TEXT, value: string)
• VariantComponentProperty (VARIANT, value: string, boundVariables required)
• InstanceSwapComponentProperty (INSTANCE_SWAP, value: string, preferredValues required)

ComponentPropertyDefinition

• BooleanComponentPropertyDefinition (BOOLEAN, defaultValue: boolean)
• TextComponentPropertyDefinition (TEXT, defaultValue: string)
• VariantComponentPropertyDefinition (VARIANT, defaultValue: string, variantOptions required)
• InstanceSwapComponentPropertyDefinition (INSTANCE_SWAP, defaultValue: string, preferredValues required)

The parent schemas (ComponentPropertyDefinition, ComponentProperty) become discriminator unions pointing to these subtypes.

Benefit

Code generators (e.g. openapi-typescript, openapi-generator) can produce narrowed, accurate types per type value, eliminating the need for manual type narrowing in consumer code.

[fszeto-figma]

Thanks for raising! Tracking internally with 1202050547272918/task/1213692898472468