[UoM prototype] Render measurement attributes in docs (3/4)

[ricardotejedorsanz]

What this PR does

This PR updates the public docs/visualizer path to understand measurement attributes introduced in #950 and bulk-imported in #951.

It is stacked on #951 so the visualizer can be reviewed with the V0 measurement vocabulary.

What changed

• Docs attribute serializers now emit type for attributes.
• Measurement attributes emit measurement_type and supported_units instead of a values list.
• Category and attribute visualizer pages render each attribute's type and measurement metadata instead of assuming every attribute has closed-list values.
• The root README documents the V0 attribute-type shape.

UX changes

The visualizer now makes the attribute type explicit when an attribute is expanded:

• Closed-list attributes show Type: closed_list, followed by a Values label and their allowed taxonomy values.
• Measurement attributes show Type: measurement, Measurement type, and Supported units instead of a values list.
• The dedicated attribute search/details page uses the same measurement metadata treatment, so measurement attributes can be understood outside of a category context as well.

Image 1 — closed-list attribute expanded in a category:

Image 2 — measurement attribute expanded in a category:

Image 3 — measurement attribute on the attribute details page:

Validation

• ruby -c passed for the changed Ruby serializers/tests.
• Focused docs serializer tests passed.
• bundle exec rake test:unit passed.
• bundle exec bin/product_taxonomy docs passed.
• bundle exec jekyll build --source ../docs --destination /tmp/product-taxonomy-docs-site passed.
• Verified generated unstable docs data and rendered HTML include measurement attributes with measurement_type and supported_units, and closed-list attributes with a Values label.
• git diff --check passed.

[jeanguo-png]

Non-blocking: could we default missing attribute.type to closed_list in the shared layouts? Older release docs data does not include type, so those pages will render a blank Type value even though the attributes are effectively closed-list. A small Liquid default would keep old release pages looking correct while supporting measurement attributes in the new data.

[danielpgross]

Approach looks fine (details will depend on whether we make further changes to the data model)

[danielpgross]

This is pretty terse, it might help to add some examples here for clarity

[ricardotejedorsanz]

Thanks @danielpgross, I included one-line definitions for closed_list and measurement, plus compact JSON examples for both attribute shapes:

Attribute types

Attributes include an explicit type:

• closed_list: an attribute whose value is selected from a predefined set of taxonomy values, used when consistent value standardization is needed across products.
• measurement: an attribute whose value is a number paired with a supported unit, used when products need precise measurements such as dimensions, weight, volume, or power.

Closed-list attributes include values:

{
  "id": "gid://shopify/TaxonomyAttribute/1",
  "name": "Color",
  "handle": "color",
  "type": "closed_list",
  "values": [
    {
      "id": "gid://shopify/TaxonomyValue/1",
      "name": "Black",
      "handle": "color__black"
    }
  ]
}

Measurement attributes include measurement_type and supported_units instead of values:

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

[ricardotejedorsanz]

Non-blocking: could we default missing attribute.type to closed_list in the shared layouts? Older release docs data does not include type, so those pages will render a blank Type value even though the attributes are effectively closed-list.

Thanks @jeanguo-png, addressed this in a separate follow-up commit.