Exercise 3: Is This Dependency Graph Installable? — Possible Solution
====================================================================

GIVEN
------------------------------
app -> libA, app -> libB, libA -> libC, libB -> libC, libC -> libA

STEP 1: THREE-COLOR DFS, STARTING FROM app
------------------------------
Mark app GRAY. Visit its first neighbor, libA.

Mark libA GRAY. Visit its neighbor, libC.

Mark libC GRAY. Visit its neighbor, libA.
  libA is currently GRAY (still on the active DFS path, not yet
  finished) - per this chapter's own three-color rule, this is a
  genuine back edge.

STEP 2: THE CYCLE
------------------------------
The edge libC -> libA points back to a vertex (libA) that is still
GRAY - meaning libA is an ancestor of libC on the current DFS path,
not just a previously-visited-and-finished vertex. This is exactly
the back-edge signature this chapter's own method uses to detect a
directed cycle.

RESULT: NOT INSTALLABLE
------------------------------
This dependency graph contains a cycle: libA -> libC -> libA. libA
depends (indirectly) on libC, and libC depends directly back on libA -
an impossible circular requirement. No valid installation order
exists for libA and libC while this circular dependency remains,
regardless of what order app, libA, libB, and libC are otherwise
processed in.

WHY THIS WORKS AS AN ANSWER
------------------------------
The three-color DFS trace is followed exactly per this chapter's own
method, correctly identifying libA as GRAY (not BLACK) at the moment
libC's edge points back to it, and the specific cycle (libA -> libC ->
libA) is named directly rather than just reporting "not installable"
without identifying which packages are actually responsible.