Exercise 3: The Deferred Move-Cascade Cost — Possible Solution
====================================================================

WHAT THE DEFERRED COST ACTUALLY IS
------------------------------
Per this chapter, the save() method's own full_path recomputation only ever updates the ONE page being saved - if a page with existing children gets moved to a new parent, that page's own full_path is correctly recalculated, but none of its descendants' own stored full_path values get updated to reflect their new location in the tree. Their stored paths would become stale and incorrect the moment the parent moves.

WHY IT'S ACCEPTABLE TO LEAVE THIS OPEN FOR NOW
------------------------------
Per this chapter, this gap is left open deliberately, not out of oversight - Chapter 10's own admin move/reparent feature is explicitly where this gets solved properly, once there's an actual UI action ("move this page") to attach the cascade logic to. Solving it in Chapter 2, before any admin interface exists to actually trigger a move operation in the first place, would mean writing cascade-update logic with no real caller to invoke it yet - premature relative to what the project actually needs at this stage. Naming the gap now, rather than discovering it as a surprise later, is presented as the actual point of flagging it here.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that only the single saved page's full_path updates, leaving descendants' stored paths stale after a move, and correctly explains why deferring the fix to Chapter 10 is a deliberate, reasonable choice rather than an oversight - there's no real UI trigger for a move operation yet at this point in the course.