docs(cart): define the continue_url destination and format

[YanisMtcr]

Motivation

The cart page says businesses SHOULD provide continue_url, and the schema describes it as "URL for cart handoff and session recovery", but nothing says where the URL should lead or what it has to preserve. The requirements list still carries TODO: discuss continue_url destination - cart vs checkout from #73, where two readings met: for some implementers the URL is the checkout URL, for others the business decides the intended use (convert to checkout, or keep building the cart).

The checkout page answers the same questions for checkout in its Continue URL section (availability, format, server-side state or permalink); the cart page has no equivalent. And the permalink specification already lets a business merge items into an existing cart, create a new cart, or stage a checkout, so the destination question has an answer elsewhere in the spec: the business chooses.

This came up while implementing the cart capability: a cart session is served by the business's UCP endpoint, which does not always share state with the storefront, and a continue_url pointing at the storefront's own cart page lands the buyer on an empty basket.

What this PR changes

• shopping/cart/index.md - adds a ## Continue URL section after Cart-to-Checkout Conversion. Destination: the business chooses (cart page, checkout entry, embedded flow); whatever it picks MUST present the cart's current line_items, quantities and selected variants included, without the buyer re-adding them; items no longer available follow the permalink redirect resolution rules. Format: absolute HTTPS URL that MUST carry or reference the cart contents, using either approach the checkout page already describes by reference (server-side cart state or a stateless permalink), rather than restating them.
• Removes the TODO bullet and appends a link to the new section to the existing SHOULD bullet; the requirement level is unchanged.

Normative addition, scoped to the field: two MUSTs on continue_url (absolute HTTPS, contents preserved). Both mirror what the checkout page already requires for its own continue_url. No schema change.

Overlaps with nothing open: #740 (cart terminal status) edits the same requirements list but leaves this bullet as is, and #486 (return after handoff) is checkout-side.

Category (Required)

• 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)

Related Issues

None.

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.

[proshoumma]

Good addition to the cart capability. I'm wondering about the Platform behavior.

At which exact moment Platform is supposed to display this continue_url to the user. For checkout its clear - when an escalation is required, Platform would surface the url. However, since cart do not have a state-machine, it's not clear for Platform when to surface this.

Would be great to hear your thoughts. Also, please let me know if I missing something. 🤔

[YanisMtcr]

Not missing anything: the page does not say when the platform surfaces continue_url, before or after this PR. The platform guideline is "MAY display continue_url for handoff to business UI", and this PR only defines the business side, destination and format.

The cart has no status lifecycle (Cart vs Checkout table, Actions section), so the trigger is buyer intent or a platform-side dead end, not a status:

1. The buyer asks for it: share the cart, come back to it later, keep building on the business's site. That is the "sharing and recovery" use the page names in its introduction.
2. The buyer expresses purchase intent and the platform cannot convert the cart to a checkout, because the business does not expose the checkout capability or the platform does not support it. Same moment as the "SHOULD convert cart to checkout" guideline; when conversion is not available, continue_url is the buyer's path to complete the purchase on the business's site.
3. The cart returns a message the platform cannot act on. Cart reuses the checkout message schema, and the Create Cart example already pairs an unrecoverable error with a continue_url; requires_buyer_input carries the same handoff meaning as in checkout.

[proshoumma]

Hmm... so the only time this continue_url will come to play is either Buyer explicitly asks for it, or an error occurred during cart operations. Would be great to add a sentence or two mentioning these - Platforms will have a clear instruction to follow for when to surface the url.

[YanisMtcr]

Added a "When to surface the continue URL" list with the three situations. I kept the no-checkout case separate from errors: nothing fails there, the business exposes cart without checkout, which nothing in the capability model prevents, and the link is then the buyer's only path to purchase. It also covers the case where the buyer builds the cart on the platform and completes the purchase on the business's site.