Exercise 1: Tracing Step 6 — Possible Solution
====================================================================

WHAT markUsed ACTUALLY CALLS
------------------------------
markUsed does two things: it awaits the PATCH request to
/api/items/:id/use, and once that resolves, it calls notifyChange()
from useItemsContext(). notifyChange() does nothing more than
increment the version number held in ItemsContext - it has no
knowledge of alerts, search, or recipes at all.

HOW THAT ONE CALL REACHES BOTH FEATURES
------------------------------
useExpiryAlerts and the recipe-suggestion logic each independently call
useItemsContext() themselves and read the same version value, with
each one's own useEffect declaring version as a dependency. When
notifyChange() increments version, React re-runs every effect that
depends on it - which means useExpiryAlerts refetches /api/items/alerts
on its own, and RecipeSuggestions' own effect (or hook) refetches
/api/recipes/suggest on its own, each entirely independently and
without markUsed ever calling either one directly.

WHY NEITHER IS CALLED DIRECTLY
------------------------------
Once the milk's status is "used," Chapter 6's own alerts query
(status: "active") naturally excludes it, and Chapter 9's own expiring-
ingredients query naturally excludes it too - both queries just return
a different result now, because the underlying data changed. Nothing
about the frontend needs to specifically remove the milk from either
list; each feature's own refetch, triggered purely by the version bump,
produces the correct result on its own.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly separates what notifyChange() itself does (increment one
number, nothing more) from how each consumer's own subscription to that
number is what actually causes the refetch, and it explains why the
underlying data change alone is enough to produce correct results in
both places without any direct coordination.