Exercise 1: Caching the Checkout Page With No Exclusions — Possible Solution
====================================================================

THE SPECIFIC BUG THIS WOULD CREATE
------------------------------
Per this chapter, caching the Checkout page would serve one
pre-generated copy of that page's HTML to every visitor - but
Checkout's content (cart totals, entered billing/shipping details,
selected payment method) is different for every single customer. A
later visitor could be served a cached copy showing a previous
customer's own stale totals, or in the worst case, another customer's
own billing details rendered into the page.

WHY THIS ISN'T "JUST" A PERFORMANCE ISSUE
------------------------------
Per this chapter, this is described directly as "not a performance
bug, but a genuine data-leak bug." The chapter explicitly separates
Checkout out as a page that "must always be generated fresh, per
visitor, every time," precisely because its content is inherently
personal rather than identical for every visitor the way a blog
post's content is.

WHY "FASTER IS ALWAYS BETTER" DOESN'T APPLY HERE
------------------------------
Per this chapter, full-page caching is only safe when a page's content
is genuinely identical regardless of who requests it - the entire
premise breaks down for Checkout, so caching it isn't a faster version
of the same correct page, it's a fundamentally incorrect page being
served.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the concrete failure (stale or cross-customer
data shown on Checkout) and correctly explains why this chapter
frames it as a data-leak risk rather than merely a caching
inefficiency.