fix(rest/python): assign checkout id server side instead of trusting the request

[vishkaty]

Observed

POST /checkout-sessions returns HTTP 500 when the request carries a non-string top-level id. id is annotated ucp_request: omit (server-assigned), so a request that includes it is schema-valid and a conformant platform may send anything there — but the reference crashes on a non-string value.

Full reproducing request (a spec-valid create; the id is the only variable):

POST /checkout-sessions
UCP-Agent: profile="https://spck.dev/agent"
idempotency-key: <uuid>   request-id: <uuid>   Content-Type: application/json

{"id":123,"currency":"USD","line_items":[{"id":"li_1","quantity":1,
 "item":{"id":"bouquet_roses","price":1000},"totals":[]}],
 "payment":{"instruments":[],"handlers":[]},"status":"incomplete",
 "ucp":{"version":"2026-04-08"},"totals":[],"links":[]}
→ HTTP 500

Controls: id omitted → 201, id:"x" (string) → 201.

Root cause: the generated CheckoutCreateRequest declares no id field (omit at 2026-04-08) but extra="allow" admits a client id of any type; create_checkout read it back with getattr(checkout_req, "id", None) and passed it into Checkout(id=…), whose id is a required string, raising an uncaught pydantic ValidationError.

This is the direct sibling of #156 (which fixed the same class for currency by determining it server-side instead of reading it from the request).

Fix

services/checkout_service.py — assign the id server-side unconditionally instead of trusting the request:

-    checkout_id = getattr(checkout_req, "id", None) or str(uuid.uuid4())
+    checkout_id = str(uuid.uuid4())

The update path has no analogue (it takes the id from the URL, never a body id). Class check: every other server-managed omit field (status, totals, links, ucp, expires_at, and currency from #156) already returns 201 on a wrong-typed value; id was the last one reading the request unsanitized.

Verification

• New test test_create_assigns_id_server_side (integration_test.py, alongside fix(rest/python): determine currency server side instead of reading it from the create request #156's omit tests) fails on the old code with the exact ValidationError, passes after; kill-tested.
• Full uv run pytest: 135 passed. Happy-path client end to end: exit 0. Pinned pre-commit (ruff + ruff-format) clean.
• Live: the request above returns 201 with a server-assigned string id after the change.
• Why CI missed it: every existing test builds payloads with a string id, so a non-string id was never exercised.

Note

A few existing lifecycle tests were reusing the client-chosen id in follow-up URLs; they now use the server-returned id (what the happy-path client already did). There is an adjacent class of unrelated extras (e.g. continue_url, order, messages, platform) that still 500 by colliding with response-only fields — out of scope here; happy to send a follow-up that builds the checkout from declared request fields only.