Exercise 3: The Undo Feature Gotcha — Possible Solution
====================================================================

WHAT WOULD GO WRONG
------------------------------
If an undo feature simply set status back to "active" without doing anything else, the resulting document would be an active item with no expiryDate field at all - since deleteField() already permanently removed that field when the item was originally marked used. The item would appear active in the app (and therefore expected to have a real expiry date somewhere), but there would be no expiry date to show or to query against, since nothing in the undo action put one back.

WHY deleteField() IS THE ROOT CAUSE
------------------------------
deleteField() genuinely removes the field from the document - it isn't recoverable from that same document afterward, unlike, say, a soft-delete flag that leaves the original value intact somewhere. Once markItemUsed runs, the original expiry date is gone from that document permanently; simply reversing the status field doesn't undo the field removal, because status and expiryDate are two entirely separate fields with no relationship enforced between their values by the update operation itself.

THE ACTUAL FIX
------------------------------
A genuine undo would need to have retained the original expiry date somewhere before deleting it (for example, temporarily, in local UI state during an "undo window"), so it can be written back explicitly - or it would need to ask the user to enter a new expiry date, since the app has no way to recover a value it already told Firestore to delete.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that flipping status alone leaves the document with no expiry date because deleteField() already permanently removed it, and correctly proposes that a real fix requires either retaining the original value somewhere before deletion or asking for a new one, rather than assuming the field could simply reappear.