Exercise 1: Tracing movePage()'s Update Order — Possible Solution
====================================================================

WHAT movePage() UPDATES FIRST
------------------------------
Per this chapter and Chapter 10, movePage() first updates the moved page's own parent_id and recomputes its own full_path directly from the new parent's full_path plus its own slug, then saves that single change.

WHAT updateDescendantPaths() UPDATES AFTERWARD
------------------------------
Per this chapter and Chapter 10, only after the moved page's own full_path has been saved does updateDescendantPaths() run, walking each child, recomputing that child's full_path from the moved page's now-updated full_path plus the child's own slug, saving it, and recursing into that child's own children.

WHY THE ORDER MATTERS
------------------------------
Per this chapter, every descendant's own full_path is built directly from its parent's full_path. If updateDescendantPaths() ran before the moved page's own full_path was recomputed and saved, every descendant would be recalculated from the page's old, now-incorrect path instead of its new one, producing a tree full of stale, wrong paths. The moved page's own path has to be correct first, since everything beneath it depends on reading that value.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes movePage()'s own first step (updating and saving the moved page's path), correctly describes updateDescendantPaths()'s subsequent recursive walk, and correctly explains why performing them in that specific order is required rather than incidental.