Exercise 3: Tracing How refresh() Makes the Item Disappear — Possible Solution
====================================================================

THE CHAIN OF EVENTS
------------------------------
After markUsed's PATCH request succeeds, the item's row now has status = 'used' (set by this chapter's own route). Calling refresh() re-runs the fetch inside useExpiryAlerts, which hits Chapter 6's GET /api/items/alerts route again.

THE EARLIER CHAPTER'S CONDITION DOING THE ACTUAL WORK
------------------------------
Chapter 6's own alerts query includes WHERE status = 'active' as one of its filter conditions. Because the item's status is now 'used', it no longer satisfies that condition, so the freshly re-run query simply doesn't include it in its results anymore - the item is excluded at the database level, not removed by any frontend logic.

WHY NO FRONTEND FILTERING IS NEEDED
------------------------------
Since the alerts list the dashboard renders is always exactly whatever the backend query currently returns, and that query already excludes non-active items, the frontend never has to separately track "which items got marked used" or manually filter them out of its own local list - asking the backend again after the state change is sufficient.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly traces the sequence (PATCH updates status, refresh() re-queries), correctly identifies Chapter 6's own status = 'active' condition as the specific mechanism that excludes the now-used item, and correctly explains why this removes the need for any separate frontend filtering logic.