Exercise 2: The Briefly-Wrong Mini-Cart Count — Possible Solution
====================================================================

WHAT'S ACTUALLY HAPPENING
------------------------------
Per this chapter, the Shop and product pages are being served from
the full-page cache - meaning the initial HTML the browser first
renders, including the mini-cart icon, reflects whatever cart count
happened to exist at the moment that page was cached, not this
specific shopper's own current cart.

WHY IT CORRECTS ITSELF A MOMENT LATER
------------------------------
Per this chapter, WooCommerce's own Cart Fragments mechanism
(wc-cart-fragments.js) runs an AJAX request "after a cached page
finishes loading" to fetch the visitor-specific mini-cart markup and
swap it into the already-loaded page. The brief flash of the wrong
count is the cached page's own initial (stale) fragment being
displayed for a moment, before the AJAX request completes and Cart
Fragments swaps in the correct, personalized count.

WHY THIS IS EXPECTED BEHAVIOR, NOT A BUG
------------------------------
Per this chapter, this is exactly the mechanism described: "the
surrounding page stays fully cacheable; only the small fragment that
genuinely needs to be personal is fetched fresh." The brief delay
between the cached page rendering and the fragment swap completing is
the visible cost of that trade-off - it isn't a malfunction, it's the
two-layer caching approach (cached page + freshly-fetched fragment)
working as designed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the cached page's stale initial fragment as
the source of the wrong count, and correctly explains that Cart
Fragments' own AJAX-based swap-in is what corrects it a moment later,
framing the behavior as the intended mechanism rather than a bug.