Exercise 1: The Concrete Coordination Problem with a Third Feature Added — Possible Solution
====================================================================

WHAT CHAPTER 8's ORIGINAL APPROACH DID
------------------------------
markUsed called refresh() directly on the one hook it happened to have a reference to - useExpiryAlerts. That worked because, at that point in the course, alerts was the only feature that needed to react to an item being marked used.

WHAT BREAKS WITH A THIRD FEATURE INVOLVED
------------------------------
Once recipe suggestions also need to react to the same mutation (an ingredient that's no longer expiring shouldn't keep influencing recipe matches), markUsed would need a second direct call added to whatever hook backs RecipeSuggestions - and the search feature would need a third, if it's also supposed to reflect the updated status. Every single place an item gets mutated (adding an item, marking one used, and anything added in the future) would need its own growing list of manually-wired refresh calls, one per feature that happens to care.

WHY THIS DOESN'T SCALE
------------------------------
This is a real coordination cost that grows with both the number of mutation points and the number of features that care about item changes - adding one more feature later means going back and editing every existing mutation site to add one more call, rather than the new feature simply being able to plug itself in independently.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains what the original direct-refresh approach did and why it worked with only one dependent feature, and correctly identifies the growing, multiplying wiring cost that appears once a second and third feature need to react to the same underlying mutation.