Exercise 1: The Coordination Problem With Direct refresh() Calls — Possible Solution
====================================================================

THE PROBLEM ONCE A THIRD FEATURE IS INVOLVED
------------------------------
Chapter 8's markUsed calls refresh() on useExpiryAlerts directly - it
has a reference to that one hook's own function and calls it after a
successful PATCH. That works when exactly one feature (alerts) needs
to react. Once recipe suggestions also needs to update (an ingredient
that's no longer expiring shouldn't keep influencing recipe matches),
markUsed would need a second direct reference to whatever function
refreshes RecipeSuggestions, and a call to that too. Every additional
feature that cares about item changes means going back into markUsed
(and every other place items get mutated - adding an item, and
anything added later) and wiring in one more direct call.

WHY THIS DOESN'T SCALE
------------------------------
The number of direct wiring connections needed grows with both the
number of features that care about changes and the number of places
mutations happen - roughly the product of the two, not a fixed
number. A third feature isn't just "one more line" in one place; it's
one more line in every place a mutation occurs, and that same pattern
repeats for every feature added after that.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that the real problem isn't handling one
specific new feature, but the growth pattern itself - every mutation
site needing to know about every consumer - and it explains why that
specific shape (each new feature touching every mutation site) is what
makes the approach not scale, rather than just asserting it "gets
messy."