fix(storefront): align contract collection with customer authorization and Stripe payment verification

[roncodes]

Why

The storefront contract run (e.g. fleetbase/storefront#91's contract job) fails with 10 assertions since two intentional security fixes landed in dev-v0.4.20:

• Authorize Storefront customer profile updates storefront#94 — customer updates now require the Customer-Token of the customer being updated. Update a Customer and Update Contact Customer Alias sent no Customer-Token at all (only the store key), so both answer 403 Not authorized to update customer.
• Verify Stripe payment before Storefront order capture storefront#95 — capture now requires a succeeded Stripe PaymentIntent. The run cannot complete a card payment, so capturing the stripe checkout can only ever answer 402 Stripe payment has not been completed. — and with no order created, Complete Order Pickup and Get Order Receipt cascade into No order found.

What changed

• Customer/Update a Customer, Customer/Update Contact Customer Alias: send Customer-Token: {{customer_token}} — the token Authenticate a Customer captures, which belongs to the same {{customer_id}} both requests target. Descriptions document the authorization contract.
• New Checkout/Before Cash Pickup Checkout: initializes a cash pickup checkout — no provider payment and no service quote (documents the Fix cash pickup checkout without delivery quote storefront#93 behavior). Saves cash_checkout_token without touching the stripe checkout's variables, which Get Checkout Status and the QPay callbacks still use.
• Checkout/Capture checkout as order: captures the cash checkout, so the run creates a real order again and {{order_id}} flows to the order requests.
• New Checkout/Capture Stripe checkout without payment: explicit negative contract — asserts 402 and the exact Stripe payment has not been completed. error for the unpaid stripe checkout.
• Collection baseline script: a request whose contract is a refusal can set expected_status in its beforeRequest script; the baseline then asserts that status instead of 2xx and skips the error-payload check for it.

Companion PR (merge order matters)

The CI orderer (scripts/ci/order-collection-requests.py in fleetbase/fleetbase) must add the two new requests to the storefront RUN_LATE sequence — companion PR in fleetbase/fleetbase. Merge this PR first: until the companion lands, the two new requests run in the ordinary phase before their variables are set (two transient failures). Merging the companion first would abort the whole run (unresolvable -i flags).

Validation

• npm run postman:lint — Fleetbase Storefront API: 62 items scanned, 0 errors, 0 warnings (all collections clean).
• Server-side behavior verified against the storefront dev-v0.4.20 code: cash pickup before returns {checkout, token} with no quote required; capture of a cash checkout creates the order; receipt for a cash order answers 200 with no error key; both update routes 200 when the token owner matches.

Docs impact

The collection doubles as published API reference: the two new requests document the fleetbase/storefront#93 (cash pickup without quote) and fleetbase/storefront#95 (402 refusal) behaviors, and the update-request descriptions now state the fleetbase/storefront#94 authorization contract. fleetbase/fleetbase.io regeneration may be needed after merge.