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

WHAT movePage UPDATES FIRST
------------------------------
Per this chapter and Chapter 10, movePage() first looks up the page
being moved, computes its new fullPath from the new parent via
computeFullPath(), and updates that single page's own parentId and
fullPath columns, saving that change immediately.

WHAT updateDescendantPaths UPDATES AFTERWARD
------------------------------
Per this chapter and Chapter 10, only after the moved page's own
fullPath has been saved does updateDescendantPaths() run, looking up
each direct child, rebuilding that child's own fullPath from the
moved page's now-current fullPath plus the child's own slug, saving
it, and recursing into that child's own children afterward.

WHY THE ORDER MATTERS
------------------------------
Every descendant's own fullPath is built directly from its parent's
fullPath. If the recursive walk ran before the moved page's own path
was saved, every descendant would be recomputed from the stale,
pre-move path instead of the correct new one, leaving the whole
subtree with wrong paths.

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