fix: accept 200 or 201 for checkout-session creation in test_buyer_consent

[vishkaty]

Description

test_buyer_consent asserts an exact 201 for POST /checkout-sessions
(business_logic_test.py:432), while the rest of the suite accepts [200, 201]
for the identical operation. This is an internal inconsistency: 200 is a
spec-legitimate outcome for this endpoint, so the exact-201 assert can fail a
conformant server.

Why 200 is legitimate here

• The pinned 2026-04-08 status-code table lists both 200 OK and
  201 Created as success responses (checkout-rest.md, status table
  ~L1254–1266); neither is bound to a specific endpoint.
• Business outcomes are returned with HTTP 200 and the UCP envelope
  carrying messages (checkout-rest.md ~L1275, normative) — this applies to
  the create path, so a create that surfaces a business outcome legitimately
  returns 200.
• The idempotency path ("MUST return the cached result" on Idempotency-Key
  replay) does not pin the replay status.

For completeness: source/services/shopping/rest.openapi.json documents 201
as the success response for POST /checkout-sessions. That responses map is
non-exhaustive (it documents no 4xx/5xx either), so it does not mandate
201 to the exclusion of the 200 cases above — it's the illustrative happy
path, not a MUST that forbids 200.

The suite's own convention

[200, 201] is already accepted for this same operation in five sibling
sites, including the shared helper every other test creates sessions through:

• integration_test_utils.py:914 — the shared create_checkout_session helper
• protocol_test.py:328
• idempotency_test.py:60
• fulfillment_structure_test.py:253
• validation_test.py:87

business_logic_test.py:432 is the sole outlier.

Change

One line — assert_response_status(response, 201) →
assert_response_status(response, [200, 201]).

The check stays sound: assert_response_status uses assertIn, so any status
outside [200, 201] (e.g. 4xx/5xx) still fails. test_buyer_consent
verifies consent persistence; session creation is scaffolding and the assert
carries no other creation-distinctness signal, so nothing is lost.

Category (Required)

• Conformance: Conformance test suite updates.