Exercise 1: Moving the Bug to Stage 1 — Possible Solution
====================================================================

THE BUG
------------------------------
    def validate_cart_BUGGY(items):
        return [i for i in items if i['qty'] >= 0]  # lets qty=0 items through

RESULTS
------------------------------
    Unit test against validate_cart_BUGGY:
      FAILED: expected 1 item, got [{'price': 10, 'qty': 2}, {'price': 5, 'qty': 0}]
      -> unit suite immediately names validate_cart as broken: 1 targeted check

    e2e test with the bug in place:
      expected $26.60, got $26.60, PASSES: True

    -> the e2e test does NOT fail at all. Blind bisection has nothing to
       find, because the bug never produces an observable symptom in
       this scenario.

WHY THE E2E TEST DOESN'T CATCH THIS ONE
------------------------------
calculate_subtotal computes price * qty for each item. A qty=0 item
contributes exactly $0 to the subtotal whether or not it was filtered
out by validate_cart - the bug (letting qty=0 items through) can never
change the final total, by the arithmetic itself, regardless of what
that item's price is. The unit test catches it because it inspects the
LIST validate_cart returns directly; the e2e test only ever observes
the final dollar total, which this particular malformed item cannot
affect.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is a stronger, more honest finding than the chapter's own
Exercise 1 prompt anticipated - not just "e2e localizes slower," but
"e2e doesn't detect this bug at all." It reveals a genuine limit on
the chapter's own fault-localization argument: bisection assumes every
bug propagates to an observable symptom somewhere downstream, but a
bug can sit in code whose specific defect happens to be arithmetically
invisible to whatever the e2e test actually checks. A unit test that
inspects a stage's own output directly has no such blind spot - it
doesn't rely on the bug happening to matter three stages later.