Record fallback cache lifetime for blocking PPR routes (#97821)
A dynamic route that can't serve an HTML fallback (`fallback: null`,
e.g. because its cached shell is keyed on the route params) still
produces cacheable fallback artifacts during the build: the per-segment
prefetch payloads served to the client Segment Cache, and the RSC
template. Previously the prerender manifest only recorded
fallbackRevalidate/fallbackExpire when the HTML fallback itself was
servable, so these routes shipped their segment and .rsc outputs with no
lifetime at all.
Cache layers interpret a missing revalidate as a 1-second lifetime —
both deployment infrastructure and the self-hosted incremental cache
(calculateRevalidate). The result is that every segment entry for such a
route goes stale one second after it's written, so nearly every prefetch
of a non-prerendered URL serves stale, triggers a background
revalidation, and writes a new cache entry. On a site with dynamic
product/listing routes and default viewport prefetching, this amplifies
into millions of cache writes per hour.
The build already computes the correct lifetime: the export's collected
cache control, which describes exactly the caches that completed into
the fallback artifacts. The manifest now records it for every PPR route
regardless of fallback mode, and the adapter's segment and RSC template
outputs fall back to the manifest values when there's no HTML fallback
output to inherit them from. When the export collected no cache control,
the lifetime is `false` (keep until invalidated), matching how servable
fallbacks are already treated.
fallbackStatus and fallbackHeaders remain gated on the PRERENDER
fallback mode because they describe the prerendered fallback response
itself, which doesn't exist for blocking routes.
