feat!: Support fractional quantities and location context for grocery shopping use cases

[jingyli]

Description

Addressing 2 gaps that would extend existing UCP shopping service schema/capabilities to support hyper-local goods (i.e. grocery) use cases:

1. Weighted and Measured Items: Right now, quantity representation is rigid and can only express countable goods.
2. Store/Branch Context: Enable platform to provide location hints on top of user addresses, especially if the user has a known "favourite store".

Key Design Decisions

1. Unified anyOf Union for quantity

• Problem: We need to support fractional weights (e.g., 1.5 lbs) while maintaining integer support for standard items.
• Solution: Modify the quantity property to be an anyOf union of a standard integer and a $ref to a new shared common/types/measure.json object. An example of the modification in line_item.json:

  "quantity": {
    "anyOf": [
      {
        "type": "integer",
        "description": "Quantity of the item being purchased.",
        "minimum": 1
      },
      {
        "$ref": "../../common/types/measure.json",
        "properties": {
          "value": { "exclusiveMinimum": 0 }
        },
        "description": "The precise fractional quantity and unit of the item being purchased."
      }
    ]
  }

2. Standardized location Field in context.json

• Problem: Cart pricing & availability for these purchase journeys are often tied to specific physical stores, which requires passing a store identifier as hint to businesses (if the location is retrieved through upper-funnel journeys like catalog search).
• Solution: Add an optional location string property directly to context.json. This also allows the hint to be overwritten by more authoritative data constructs like filters.fulfills_to in catalog_search and fulfillment extension's pickup location ID.

Category (Required)

Please select one or more categories that apply to this change.

• Core Protocol: Changes to the base communication layer, global context, or breaking refactors. (Requires Technical Council approval)
• Governance/Contributing: Updates to GOVERNANCE.md, CONTRIBUTING.md, or CODEOWNERS. (Requires Governance Council approval)
• Capability: New schemas (Discovery, Cart, etc.) or extensions. (Requires Maintainer approval)
• Documentation: Updates to README, or documentations regarding schema or capabilities. (Requires Maintainer approval)
• Infrastructure: CI/CD, Linters, or build scripts. (Requires DevOps Maintainer approval)
• Maintenance: Version bumps, lockfile updates, or minor bug fixes. (Requires DevOps Maintainer approval)
• SDK: Language-specific SDK updates and releases. (Requires DevOps Maintainer approval)
• Samples / Conformance: Maintaining samples and the conformance suite. (Requires Maintainer approval)
• UCP Schema: Changes to the ucp-schema tool (resolver, linter, validator). (Requires Maintainer approval)
• Community Health (.github): Updates to templates, workflows, or org-level configs. (Requires DevOps Maintainer approval)

Checklist

• I have followed the Contributing Guide (including Conventional Commits title requirements and ! for breaking changes).
• I have updated the documentation (if applicable).
• My changes pass all local linting and formatting checks.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• (For Core/Capability) I have included/updated the relevant JSON schemas.
• I have regenerated Python Pydantic models by running generate_models.sh under python_sdk.

Screenshots / Logs (if applicable)

[jamesandersen]

Thanks @jingyli for introducing a formal measurement type to reuse across UCP. I left a couple comments inline for some things I've encountered working in this domain in the past.

[jamesandersen]

Do we need to make this an array of saleable units to support the grocery use case? e.g. with a wide variety of units a business may offer multiple units e.g. "bags" and "ounces" of black beans?

[jamesandersen]

With the grocery use case in mind there are some key product/variant metadata that users need to be aware of during consideration because they have implications for payment and/or fulfillment e.g.

• SNAP EBT eligibility - the item qualifies for use of an EBT payment method
• Firearm Owners ID verification required, etc. - The ID must be shown to pickup items. (NOTE: while it seems strange to mention this in the context of grocery, many large grocery stores in the US at least have large sporting goods sections as well)

This may be belong in a separate PR but - in the interest of platforms / businesses mutually understanding some of these concepts I'm wondering if a schema of domain specific standard tags for these types of consequential concepts makes sense.

Minimally, if we intend for either tags or metadata to be use to carry these types of attributes would we want to tweak the descriptions?

[jamesandersen]

Should we call this retail_location to match the fulfillment extension? (and avoid confusion with "locality")

[jamesandersen]

For the grocery use case I think we'll need a line-item level note field. Some examples:
Simple Guidance

• "Make sure the bananas are green"
• "Find the ripest mango - I'll need it next week"

Substitution guidance that, during fulfillment, could be captured in the order adjustments:

• "Substitute with non-organic if organic isn't available" ... or "Don't substitute"
• "Substitute with the store brand if this brand isn't available"
• "Get two dozen medium eggs if large aren't available"

[jamesandersen]

Just noticed #607 that relates.