Exercise 3: The Nightly Restart's Connection to Chapter 1 — Possible Solution
====================================================================

CHAPTER 1's ORIGINAL WARNING
------------------------------
Per Chapter 1, restarting a struggling process "destroys the exact
evidence" needed to diagnose why it happened - accumulated memory
usage resets, open file handles close, and current activity vanishes
the moment the process exits.

HOW THIS CHAPTER'S EXAMPLE IS THE LONGER-TERM VERSION OF THAT WARNING
------------------------------
Per this chapter, "here's the longer-term version of that same
warning - a nightly restart didn't just destroy evidence once, it's
been quietly masking a real problem for so long that nobody remembers
it's a problem at all." Instead of one restart destroying evidence
from one incident, a *scheduled, repeated* restart destroys the
evidence every single day, over and over, before anyone ever gets the
chance to notice the underlying pattern building up across days.

WHY WEEKS OF NIGHTLY RESTARTS MADE THE PROBLEM HARDER TO NOTICE
------------------------------
Per this chapter's own worked example, checking only the daily graph
shows the same reassuring "climbs to 85%, drops to 40%" pattern every
single day, which looks stable and repeating at a glance - each
restart resets the visible symptom back to something that looks fine,
so there's never an obvious moment where things look obviously worse
than before. Only by specifically tracking the post-restart floor over
several weeks (9.2 GB, 8.1 GB, 6.9 GB, 5.8 GB) does the real,
slowly-worsening trend become visible - a trend the daily reset was
actively hiding, not revealing.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects Chapter 1's original single-restart warning to this
chapter's repeated-restart scenario as the same underlying mistake
happening at two different scales, and explains specifically why the
repeated resets made the trend harder to spot rather than simply
irrelevant to it.