next.js

23fa2787 - Fix inconsistent cache life/tags propagation for cache handler hits (#91454)

Fix inconsistent cache life/tags propagation for cache handler hits (#91454) When a `"use cache"` entry is newly generated during a prerender (`prerender` or `prerender-runtime`), `collectResult` defers propagation of cache life and tags to the outer context. This is because the entry might later be omitted from the final prerender due to short expire or stale times, and omitted entries should not affect the prerender's cache life. However, when a cache handler returns a hit for an existing entry, `propagateCacheEntryMetadata` was called unconditionally, without the same deferral logic. This meant that short-lived cache entries retrieved from the cache handler could propagate their cache life to the prerender store, even though they would later be omitted from the final render. This inconsistency is currently not observable because runtime prefetches use a prospective and final two-store architecture (see `prospectiveRuntimeServerPrerender` and `finalRuntimeServerPrerender` in `app-render.tsx`). The cache handler hit propagation corrupts the prospective store, but the response is produced from the final store, which reads from the resume data cache with correct stale and expire checks. Static prerenders have a similar two-phase architecture that masks the issue. Because of this, there is no test case that can observe the incorrect behavior, but the fix avoids confusion and prevents the inconsistency from becoming a real bug if the architecture changes. This change extracts a `maybePropagateCacheEntryMetadata` function that encapsulates the conditional propagation logic and is now called from both the generation path (inside `collectResult`) and the cache handler hit path. The resume data cache read path continues to call `propagateCacheEntryMetadata` unconditionally, since it runs in the final render phase after short-lived entries have already been filtered out.