Challenge 2: Trace a Three-Level Query — Possible Solution
====================================================================

QUERY: { user(id: 5) { posts { comments { text } } } }

STEP-BY-STEP TRACE
--------------------

1. Query.user's resolver runs, with args.id === 5. It looks up and
   returns a specific User object (call it userObj).
   -> parent for THIS resolver: not applicable — this is a root-level
      Query field, so there's no parent object one level up from it.

2. User.posts's resolver runs.
   -> parent for this resolver: userObj, the User object returned in
      step 1. The resolver reads parent.id (userObj's own id, which
      happens to be 5 in this case, but the resolver has no idea it
      came from an "id: 5" argument up at the Query level — it only
      knows parent.id) to look up that user's posts, returning an array
      of Post objects (call them postsArray).

3. For EACH post in postsArray, Post.comments's resolver runs once per
   post.
   -> parent for each of these resolver calls: one individual Post
      object from postsArray. The resolver reads parent.id (that
      specific post's own id) to look up its comments, returning an
      array of Comment objects for that post.

4. For EACH comment returned in step 3, the text field is resolved.
   -> Since no custom resolver is needed for a plain scalar field like
      text (assuming Comment.text matches a property already present on
      the comment object), the DEFAULT resolver runs, reading
      parent.text directly. parent here is one individual Comment
      object from step 3's results.

WHY THIS WORKS AS A TRACE
----------------------------
- The critical detail this trace demonstrates is that "parent" is
  reassigned completely fresh at EVERY level, and it is always exactly
  one level's worth of "whatever the field directly above just
  returned" — never the original id: 5 from the very top of the query.
  By step 4, the resolver has no way to know (or need to know) that this
  chain started from a query for user 5 — it only ever sees the
  Comment object immediately above it.
- Step 3 also demonstrates that a resolver can run MULTIPLE times in a
  single query execution — once per item in the array the previous
  level returned — which is exactly the shape of behavior that becomes
  a performance concern in Chapter 5's N+1 problem: if postsArray has 10
  posts, Post.comments's resolver runs 10 separate times, once per post,
  each potentially issuing its own separate database query.