Exercise 2: revalidateTag's New Argument, and Why updateTag Was Chosen — Possible Solution
====================================================================

WHY revalidateTag NOW NEEDS A SECOND ARGUMENT
------------------------------
Per this chapter, Next.js 16 requires revalidateTag to be called with
an explicit cacheLife profile as a second argument (e.g.
revalidateTag(tag, 'max')) - the old single-argument form is deprecated
and produces a TypeScript error. This makes the staleness behavior
explicit at the call site rather than relying on an implicit default,
matching the framework's own broader shift (seen already in Chapter 1)
toward making previously-implicit behavior mandatory and visible.

WHAT "READ-YOUR-WRITES" ACTUALLY MEANS HERE
------------------------------
An admin who just called updatePageTitle to rename a page expects to
see that new title the very next time they load the page - not "soon,"
not "within a few seconds," but immediately, on their own very next
request. revalidateTag marks the cached data stale and allows it to
refresh in the background, which means a request landing in the brief
window between the mutation and the background refresh could still
serve the old, pre-edit title - a real, if usually short-lived,
inconsistency.

WHY updateTag WAS CHOSEN INSTEAD
------------------------------
updateTag expires and refreshes the relevant cache entry within the
same request the mutation itself runs in, per this chapter. That
guarantees the admin's own next page load - which happens after the
Server Action has already fully completed - reflects the new title with
certainty, not just high probability. revalidateTag remains the right
tool for content where a brief delay is genuinely acceptable (this
chapter names blog posts and product catalogs as that category
elsewhere in this course's own material); an admin's own immediate edit
confirmation is specifically the case updateTag exists for.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the mechanical reason for the new required argument (making
staleness tolerance explicit), and correctly distinguishes
revalidateTag's own background-refresh behavior from updateTag's
same-request guarantee, tying the choice directly to what an admin
editing their own content actually needs to see happen.