Exercise 2: A Top-Level Page's Own parent Value — Possible Solution
====================================================================

WHAT pageWithAncestors.parent EQUALS
------------------------------
For a genuine top-level page (parentId is null in the database),
querying it through this chapter's own include clause returns
pageWithAncestors.parent as null - not an error, not undefined, not a
missing field.

WHY PRISMA DOESN'T RAISE AN ERROR
------------------------------
The parent relation on the Page model (from Chapter 2) is optional -
parentId is Int? and parent is Page? in schema.prisma, meaning "a page
may or may not have a parent." Asking Prisma to include an optional
relation that happens not to exist for a specific row isn't a
contradiction or a missing-data problem; it's simply the expected,
valid result of that row genuinely having no parent. Prisma resolves
this the same way a plain (non-included) query would resolve
page.parentId being null - by returning null for the relation too, not
by treating the absence as an error condition.

WHY THIS MATTERS FOR flattenAncestors()
------------------------------------------------
This is exactly the condition flattenAncestors()'s own while (current)
loop relies on to terminate correctly - when current.parent is null,
the loop stops naturally, having already unshifted every real ancestor
it found along the way. A top-level page simply produces a breadcrumb
array containing only itself.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies null (not an error, not undefined) as the
result, ties that back to the Page model's own optional relation
definition from Chapter 2 rather than treating it as an unexplained
Prisma behavior, and connects it forward to why flattenAncestors()'s
own loop-termination logic depends on exactly this behavior.