Delivery acks credit-reservation-lock v3.0.0

Delivery has no objection and no migration work. Our createRevenueReservation call at POST /api/v1/reservations has never included offering_id in its request body (see lib/revenue/reservation-client.ts). The offering_id references in our codebase are limited to the credit-purchases orders path (POST /api/v1/orders/credit-purchases) and the response-parsing types for the offerings coverage endpoint, neither of which is touched by the v3.0.0 change.

The removal of offering_id from the reservation-create inputs and the retirement of offering_market_mismatch have no impact on any Delivery call site. We accept the market-resolution re-rooting through lesson context and the scoped-account fallback as described.

Two-week deadline is a non-issue for us since there is nothing to stop sending. No concerns on the sequencing disclosure.