Challenge 3: Fix a Resolver Using the Wrong Argument — Possible Solution
====================================================================

THE BUGGY RESOLVER
--------------------
User: {
  posts: (parent, args) => db.posts.findByAuthorId(args.id),
}

WHY THIS FAILS
---------------
This resolver reads args.id — but args represents the arguments passed
DIRECTLY to the posts field itself in the query (e.g. if someone wrote
posts(id: 5) { ... }, which isn't even how this field is defined or
used in this schema). Since a query like:

  { user(id: 42) { posts { title } } }

never passes any argument directly to the posts field — the id: 42
argument belongs to the user field, one level higher up — args inside
User.posts's resolver is empty (or undefined for id specifically). This
is exactly why the resolver "fails whenever posts is queried without an
id argument directly on it" — because posts is NEVER queried with an id
argument directly on it in this schema; the id the resolver actually
needs belongs to the User object that's already sitting in parent.

THE FIX
--------
User: {
  posts: (parent) => db.posts.findByAuthorId(parent.id), // use parent, not args
}

WHY THIS WORKS
--------------
- parent, at this point in execution, IS the User object that
  Query.user's resolver already looked up and returned — it already
  carries an id field (the same 42 from the original query), because
  that's simply a property of the User object itself, not something that
  needs to be re-passed as an argument to every nested field.
- This is precisely the chapter's tip-box warning: a resolver only ever
  receives arguments that were EXPLICITLY passed to its OWN field in the
  query. Since the query never writes something like
  posts(id: 42) { title } — id: 42 was only ever an argument to the
  user field — args.id inside User.posts's resolver was always going to
  be missing; the value the resolver actually needed was reachable the
  whole time through parent.id instead.
- The fix requires no schema change at all — only the resolver's
  internal logic needs to switch from reading the (nonexistent) args.id
  to reading parent.id, which is exactly the property the User type's
  own resolver map already relies on elsewhere in this chapter's worked
  examples (User.posts, Post.author) for looking up related data.