Exercise 2: Why chapter1.full_path Is Already Correct After the Move — Possible Solution
====================================================================

WHY chapter1's OWN full_path UPDATES WITHOUT BEING TOUCHED DIRECTLY
------------------------------
Per this chapter, move_page(gpl, languages) was only ever called with gpl as its argument - chapter1 was never passed into that function or referenced directly anywhere in the call. Yet chapter1.full_path is already correct immediately afterward (once refresh_from_db() reloads it), because Chapter 10's own move_page performs a breadth-first cascade: after gpl itself is saved with its new parent, every one of gpl's descendants gets its own .save() called too, in parent-first order - first java (gpl's child), then fundamentals (java's child), then chapter1 (fundamentals's child).

WHY THIS WORKS WITHOUT ANY MANUAL EDITING
------------------------------
Per this chapter, none of those .save() calls manually edit full_path - each one simply re-triggers Chapter 2's own save() override, which recomputes full_path from parent.full_path at the moment it runs. Because the cascade processes java before fundamentals, and fundamentals before chapter1, each page's own parent is already correct by the time that page's own save() runs - so chapter1.full_path ends up correct not because it was directly updated, but because it was three levels down in a cascade that correctly updated every page in between it and the page that was actually moved.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that move_page's own breadth-first cascade reaches chapter1 indirectly, three levels below gpl, and correctly explains that each intermediate page's save() call - relying on Chapter 2's own save() override - is what produces the correct final result without any direct reference to chapter1 anywhere in the move_page call itself.