Exercise 1: A Third Polluted Test — Possible Solution
====================================================================

THE SEQUENCE
------------------------------
    inventory['PROD-1'] = 100      # reset once, before test 1 only
    r1 = sell_item_impure('PROD-1', 30)   # test 1: expect 70
    r2 = sell_item_impure('PROD-1', 50)   # test 2 (this chapter's own): expect 50
    r3 = sell_item_impure('PROD-1', 10)   # test 3 (new): "sell 10 from a fresh 50", expect 40

No reset happens between any of the three calls - exactly matching
this chapter's own test-pollution scenario, extended by one more test.

RESULTS
------------------------------
    after test1 (sell 30): 70
    after test2 (sell 50): 20
    after test3 (intended: sell 10 from fresh 50, expect 40): 10

Test 3 returns 10, not the expected 40.

TRACING WHY, THROUGH THE ACTUAL STATE LEFT BEHIND
------------------------------
inventory['PROD-1'] starts at 100. Test 1 leaves it at 70 (100-30).
Test 2 - which THINKS it's starting from a fresh 100 - actually starts
from 70, leaving it at 20 (70-50), not the 50 its own test description
claims. Test 3 - which THINKS it's starting from a fresh 50 - actually
starts from 20 (whatever test 2 left behind), leaving it at 10 (20-10),
not the 40 it expected. Each test's own wrongness compounds directly
from the PREVIOUS test's own leftover state - there's no reset point
anywhere in the sequence, so every test after the first is silently
testing against whatever arbitrary number the tests before it happened
to leave behind.

WHY THIS CONFIRMS THE BUG COMPOUNDS, NOT JUST REPEATS
------------------------------
This chapter's own two-test example showed ONE test corrupted by ONE
prior test. This exercise shows the corruption accumulating across
THREE tests, each one further from its own intended starting
assumption than the last. A real test suite with dozens of tests
against shared, unreset state wouldn't fail predictably - it would fail
in a way that depends entirely on which other tests happened to run
before it and in what order, exactly the kind of bug that's
notoriously hard to reproduce and debug.

WHY THIS WORKS AS AN ANSWER
------------------------------
A third test is added directly on top of this chapter's own existing
two-test sequence with no reset introduced, the actual returned value
is verified rather than assumed, and the explanation traces the exact
state each test left behind for the next one, showing precisely where
the expected and actual values diverge.