[UoM prototype] Add measurement attribute support prototype (1/3)

[ricardotejedorsanz]

What this unblocks

This PR introduces the first public taxonomy package support for measurement-based attributes. Today, taxonomy attributes are effectively all closed-list attributes backed by predefined values. This change adds the minimum schema/model/dist support needed for attributes whose value is a measurement with supported units.

The goal of this first PR is to unblock downstream review and integration work with one concrete example, while keeping the broader vocabulary rollout and tooling work separated into follow-up PRs.

Example: Height on Bird Cage Accessories

This PR adds a new Height measurement attribute and assigns it to Animals & Pet Supplies > Pet Supplies > Bird Supplies > Bird Cage Accessories (ap-2-1-1).

In source data, it looks like:

- id: 12429
  name: Height
  description: Specifies the vertical measurement from bottom to top, determining space requirements and compatibility with other items.
  friendly_id: height
  handle: height
  type: measurement
  measurement_type: dimension
  supported_units:
  - cm
  - in

In the public dist attribute JSON, it emits as:

{
  "id": "gid://shopify/TaxonomyAttribute/12429",
  "name": "Height",
  "handle": "height",
  "type": "measurement",
  "measurement_type": "dimension",
  "supported_units": ["cm", "in"]
}

Category attribute references now also include the attribute type, so consumers can distinguish measurement attributes from closed-list attributes.

Explicit closed-list attributes

Since attributes are no longer all implicitly closed-list attributes, this PR makes the existing vocabulary explicit by adding:

type: closed_list

to existing base attributes, and by emitting:

"type": "closed_list"

in generated dist JSON for closed-list attributes and category attribute references.

Other changes in this package

To support this first measurement attribute package, this PR also updates:

• Ruby taxonomy attribute model loading and validation
• attribute data/dist serializers
• category dist serializer attribute references
• CUE schemas for source and generated dist files
• tests covering measurement attributes, explicit closed-list attributes, and generated dist output
• generated dist/en files

Measurement attributes require measurement_type and supported_units, and do not use predefined values.

Follow-ups

This PR intentionally keeps the scope to the first unblocker package. Follow-up stacked PRs will cover:

• the full measurement vocabulary rollout/alignment
• downstream dependency updates, including tooling such as the visualizer

[translation-platform]

Localization quality issue found

The following issues may affect the quality of localized translations if they are not addressed:

• The value Height for key en.attributes.height.name is very short. Short strings are more likely to be misunderstood by translators without context. Please provide additional context for the translators if possible.

Please look out for other instances of this issue in your PR and fix them as well if possible.

Questions about these messages? Hop in the #help-localization Slack channel.

[jeanguo-png]

Could we pass type, measurement_type, and supported_units from the base attribute into ExtendedAttribute? Right now an extended attribute based on a measurement attribute would default back to closed_list and lose its unit metadata. V0 does not include that case yet, but this would be easy to miss later.

Could we tighten the CUE schema so the attribute shape depends on type? closed_list should require values and disallow measurement metadata; measurement should require measurement_type/supported_units and disallow values. Ruby validation catches this today, but the schema should protect the public/source contract too.

[jeanguo-png]

Requesting changes for the measurement attribute contract edge cases:

• ExtendedAttribute should inherit type, measurement_type, and supported_units from its base attribute so future measurement-based extended attributes do not silently serialize as closed_list.
• The CUE schemas should make the shape depend on type: closed_list requires values and disallows measurement metadata; measurement requires measurement_type/supported_units and disallows values.

Ruby validation catches the current source data, but these should be enforced at the model/schema contract level before this becomes public.