RevalidateTag With Longer Duration Overrides Earlier Immediate Expiration For Same Tag

In FileSystemCache.revalidateTag and the default 'use cache' handler's updateTags, the expired timestamp is set unconditionally to now + duration * 1000. A later call with a longer expiration profile replaces the pending immediate expiry, so the tag is no longer considered expired.

1. Set up Next.js with 'use cache' and cacheLife('max') for a tagged entry. 2. Request the page twice to cache content. 3. Change underlying data. 4. In a route handler, call revalidateTag(tag, { expire: 0 }) and then in a later request call revalidateTag(tag, 'max'). 5. Request the page again and observe that the response is STALE with old data instead of a blocking MISS.

This fix changes the semantics from last-call-wins to earliest-expiration-wins, which may affect applications relying on the previous behavior. In multi-process or distributed caching scenarios, race conditions could still occur if tags are updated concurrently across processes. Rollback advice: if this change causes unexpected cache lifetime extension, revert to unconditional overwrite and document the behavior as last-call-wins.