Challenge 1 — Solution

Task: Explain, using this chapter's own PHP example, exactly what kind
of mistake becomes possible when a tracking file is trusted without
verifying it against the real content on disk.

The mistake this example shows is treating a tracking file's own
CLAIM of completeness as equivalent to the content actually existing -
when the two had genuinely diverged. course_folder_mapping.md
recorded PHP Fundamentals, Intermediate, and Advanced as real,
generatable courses, and each one had a real, legitimate-looking
combined PDF sitting in its own pdfs/ folder as apparent proof. But the
actual chapter HTML behind two of the three courses had been
completely lost at some point, and the third had only one of its ten
chapters left - a fact the tracking files themselves gave no
indication of at all, since nothing had gone back to update them once
the drift happened.

If those tracking files had simply been trusted at face value - "the
mapping says this course exists, so it exists" - anyone relying on
that record (a future session, a different task referencing these
courses) would have confidently assumed real, complete content was
available when it genuinely wasn't. The mistake only became visible,
and only got fixed, because someone deliberately verified the
tracking files' own claims against the real, current state of content/
directly, rather than accepting the record as automatically accurate.

Notes:
- This is the exact same evidentiary discipline Chapter 1's R1 finding,
  Chapter 5's broken-back-link finding, and Chapter 6's SB10
  confirmation all demonstrate - a claim in a rules or tracking file is
  only as good as the last time it was actually checked against
  reality.
- The eventual fix (reconstructing all three PHP courses from their
  surviving PDFs, then correctly updating all three tracking files in
  the same turn each course finished) is the chapter's own worked
  example of P7 actually being followed - not as a hypothetical, but as
  the literal fix applied to this literal problem.