Challenge 1: Why utils.js Only Appears Once in the Bundle — Possible Solution
====================================================================

THE GRAPH, TRACED
------------------------------
Per this chapter's own example: app.js (the entry point) imports both
utils.js and api.js directly. api.js itself ALSO imports utils.js.
So utils.js is reachable from app.js via two separate paths — once
directly (app.js -> utils.js), and once indirectly (app.js -> api.js
-> utils.js).

WHY IT'S STILL ONLY INCLUDED ONCE
------------------------------
Per this chapter's own explanation of the dependency graph, each FILE
is one node in the graph — not one node per import statement that
references it. When the bundler builds the graph, it recognizes that
both import statements (the one in app.js and the one in api.js)
point at the exact same underlying file, utils.js. The bundler tracks
which files it has already discovered and added to the graph; when it
encounters a second import pointing at a file it has already seen, it
simply records that ANOTHER file also depends on the existing node,
rather than creating a second, duplicate copy of utils.js in the
output.

WHY THIS MATTERS
------------------------------
If the bundler instead treated every import statement as requiring
its own separate copy of the target file, any module imported from
multiple places would be duplicated in the final bundle — wasting
space, and, more seriously, potentially creating two separate
instances of what should be a single shared piece of state or
functionality. Deduplicating based on the actual FILE (not the import
statement) is what keeps the bundle both smaller and behaviorally
correct.

WHY THIS WORKS AS AN ANSWER
------------------------------
It traces both paths that reach utils.js explicitly, explains that
the graph is built per-file rather than per-import-statement (so a
file already discovered isn't re-added), and explains the practical
reason this deduplication matters rather than just stating that it
happens.