Exercise 3: Two Concurrent Orders Through One OrderService — Possible Solution
====================================================================

SETUP
------------------------------
    Order 1: widget x2, GoldDiscount, StandardShipping
    Order 2: gadget x3, PlatinumDiscount, ExpressShipping

    Both checked out through the SAME OrderService instance, sharing
    the same inventory dict.

RESULTS
------------------------------
    Order 1: $41.00 - "Charged $41.00 to card"
      hand calc: 40*0.9+5 = $41.00, match: True

    Order 2: $51.00 - "Charged $51.00 to card"
      hand calc: 45*0.8+15 = $51.00, match: True

    Inventory after both orders: {'widget': 48, 'gadget': 27}
    Expected: widget=48 (50-2), gadget=27 (30-3): True

Both orders' totals are correct and independent of each other - Order
2's platinum discount and express shipping had zero effect on Order
1's own gold/standard calculation, and vice versa. Inventory correctly
reflects both orders' own deductions, applied exactly once each.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the chapter's own final integrated system doesn't rely
on hidden shared state between separate checkouts to get the right
answer - each call to checkout() computes its own total from its own
arguments via the pure calculate_order_total(), and only
apply_inventory_changes() touches shared state, exactly once per
order, regardless of how many other orders pass through the same
OrderService instance before or after it. This is the direct payoff of
Step 2's own purity/isolation fix: a single shared service instance
processing many genuinely different orders is now safe by
construction, not by coincidence.