Exercise 1: Reversing the Call Order — Possible Solution
====================================================================

THE TEST
------------------------------
    def resize_and_check_reversed(rect):
        rect.set_height(10)   # reversed order
        rect.set_width(5)
        expected_area = 5 * 10
        actual_area = rect.area()
        return expected_area, actual_area, expected_area == actual_area

Calling set_height() before set_width() this time, against a fresh
Square(2, 2), rather than this chapter's own original set_width-then-
set_height order.

RESULT
------------------------------
    Square, reversed call order: expected=50, actual=25, correct=False

The check still fails - correct=False, matching this chapter's own
original finding that a Square substituted for a Rectangle breaks
resize_and_check(). But the ACTUAL WRONG NUMBER is different: 25 this
time, not this chapter's own original 100.

WHY REVERSING THE ORDER CHANGES THE WRONG ANSWER, NOT WHETHER IT'S WRONG
------------------------------
Square's own set_height(10) forces BOTH width and height to 10 first;
then set_width(5) forces BOTH back down to 5 - so the object ends up
at width=5, height=5, area=25. In this chapter's own original order,
set_width(5) sets both to 5, then set_height(10) sets both back up to
10, giving width=10, height=10, area=100. In both cases, Square's own
override makes whichever method is called LAST win completely,
overwriting whatever the other dimension was supposed to be - the
specific wrong number that results depends entirely on which call
happened last, but the underlying failure (the object never actually
reaches a real 5x10 rectangle state) is the same regardless of order.

WHAT THIS REVEALS ABOUT THE NATURE OF THE VIOLATION
------------------------------
This confirms the LSP violation isn't a one-off coincidence tied to
this chapter's own specific call sequence - it's a structural property
of Square's own overrides, which make "set just the width" and "set
just the height" both impossible operations, regardless of which order
a caller happens to use them in. Any code written against Rectangle's
own contract (which promises width and height are independently
settable) will get a wrong answer from a substituted Square, no matter
how it orders its own calls - only WHICH wrong answer it gets depends
on the order.

WHY THIS WORKS AS AN ANSWER
------------------------------
The call order is deliberately reversed while keeping every other
aspect of this chapter's own test identical, the new (different) wrong
result is verified directly rather than assumed to match the original,
and the explanation traces exactly why the specific number changes
while the underlying failure does not.