[ChoicePicker] Can't express a choice among rich options (cards)

Summary

ChoicePicker options are flat {label, value} pairs, so there's no way to offer a choice among rich options — flights, hotels, plans, restaurants, search results. This is arguably the agent commerce interaction, and the basic catalog can't express it as a choice.

Current workaround, and what it destroys

The only way to build it today is N separate Cards, each containing its own Button with its own distinct action name (select_option_1, select_option_2, …). That throws away everything that made it a choice:

• The options stop being mutually exclusive on the wire. They're N unrelated buttons that merely look like a group. Nothing in the model says picking one excludes the others.
• No data binding. The selection never lands in the data model. The agent learns which option was chosen only by decoding N different action names, so the "which did they pick" signal moves from data into control flow.
• maxAllowedSelections is unavailable, making multi-select of rich options impossible — there's no equivalent at all.
• It produces the deepest component chains in the catalog (Card → List → Card → Column → Image/Text/Button), which is a smell that the model is being used against its grain.

Proposed shape

Let an option delegate its presentation to a child component, reusing the existing id-reference pattern already used by child, entryPointChild, and contentChild rather than inventing a new mechanism:

{
  "id": "lodging",
  "component": "ChoicePicker",
  "selections": { "path": "/booking/lodge" },
  "maxAllowedSelections": 1,
  "options": [
    { "value": "cedar",    "child": "cedar-card" },
    { "value": "lakeview", "child": "lakeview-card" },
    { "value": "summit",   "child": "summit-card" }
  ]
}

• label and child are mutually exclusive; label remains the simple case and nothing existing changes.
• Selection still binds to a single path; maxAllowedSelections still applies.
• Renderers that can't host arbitrary children inside an option can degrade by rendering the child's first Text as a plain label.

Why this one has a deadline

The other catalog gaps I've run into are purely additive and could land any time. This one isn't: retrofitting selection semantics onto rich options after v1.0 would be a breaking change to ChoicePicker, since consumers will have built the N-buttons workaround and any later unification changes how selection is reported. Given v1.0 is a release candidate, it seems worth deciding before the freeze — even if the answer is "use a custom catalog," having that on the record would help.