Exercise 2: Adding remove_item() to the MVP Example, and Confirming the Bypass Bug Reproduces — Possible Solution
====================================================================

THE NEW MODEL SUPPORT AND PRESENTER METHOD
------------------------------
    class TodoModel:
        # ...existing __init__/add_item unchanged...
        def remove_item(self, text):
            self.items.remove(text)

    class TodoPresenter:
        # ...existing __init__/handle_add unchanged...
        def handle_remove(self, text):
            self.model.remove_item(text)
            self.view.show_items(f"Todo list: {', '.join(self.model.items)}")

handle_remove() mirrors handle_add() exactly - it still updates the
model, THEN explicitly pushes the new state to the view. This second
explicit push is required precisely because, per this chapter's own
finding, TodoPresenterView has no way to notice the change on its own.

VERIFYING THE PRESENTER-MEDIATED REMOVAL WORKS CORRECTLY
------------------------------
    after two presenter adds: Todo list: Buy milk, Walk the dog
    after presenter remove (should update view): Todo list: Walk the dog

Calling presenter.handle_remove('Buy milk') correctly updates
view.displayed_text to reflect the removal, exactly like handle_add()
did.

VERIFYING THE BYPASS PRODUCES THE SAME STALENESS BUG AGAIN
------------------------------
    model.items after bypassing presenter: []
    view.displayed_text after bypass (should be STALE): Todo list: Walk the dog

Calling model.remove_item('Walk the dog') directly - skipping the
Presenter entirely - correctly empties model.items to []. But
view.displayed_text stays exactly as it was after the LAST
presenter-mediated call: "Todo list: Walk the dog" - genuinely stale,
reproducing this chapter's own original finding with a completely
different operation (removal instead of addition).

WHY THIS CONFIRMS THE BUG ISN'T SPECIFIC TO add_item()
------------------------------
This chapter's own original demonstration only tested the bypass
against add_item(). This exercise confirms the same staleness problem
is a property of the ARCHITECTURE (nothing notifies TodoPresenterView
except an explicit call from TodoPresenter), not of any one specific
operation - every Model mutation method shares the identical risk if
called directly.

WHY THIS WORKS AS AN ANSWER
------------------------------
The new Presenter method follows the exact push-after-mutate shape this
chapter already established, the correctly-mediated case is verified
working, and the bypass case is verified reproducing the identical
staleness bug this chapter demonstrated - with the operation
deliberately varied (removal instead of addition) to show the bug is
architectural, not operation-specific.