Exercise 2: Why move_page Uses Parent-First Order and No Manual Editing — Possible Solution
====================================================================

WHY PARENT-FIRST (BREADTH-FIRST) ORDER IS REQUIRED
------------------------------
Per this chapter, Chapter 2's own save() method recomputes a page's full_path by reading its PARENT's current full_path. If a grandchild were saved before its own direct child, the grandchild's save() would compute its full_path from a parent value that hasn't been updated yet - producing a stale, incorrect result. The breadth-first queue in move_page guarantees each page is only processed after its own parent has already been saved and corrected in this same pass, one level of the tree at a time, which is exactly what makes every save() call along the way produce a correct result.

WHY NO MANUAL full_path EDITING IS NEEDED
------------------------------
Per this chapter's own central finding, Chapter 2's save() method already recomputes full_path from parent.full_path every single time it runs, for any page - that logic doesn't need to be reimplemented or duplicated. As long as processing order respects "parent before child," simply calling the ordinary .save() method on each descendant, with no string manipulation of any kind, produces the correct cascaded result automatically - the model's own existing save() logic already does all the real work.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why parent-first ordering specifically is required (a child's save() depends on its parent's full_path already being correct), and correctly explains that Chapter 2's own save() override already handles the recomputation, making manual string editing genuinely unnecessary.