next.js

13809269 - [Segment Bundling] [Scaffolding] Ensure inlining hint correctness (#91320)

[Segment Bundling] [Scaffolding] Ensure inlining hint correctness (#91320) Inlining hints (which segments to bundle together) are computed once at build time by measuring gzip sizes, then persisted to `prefetch-hints.json`. There are several scenarios where these hints may not be available at render time. This commit addresses each scenario to ensure the client always receives correct hints and never enters a bad state. ### Build-time static pages (stale hints) The initial RSC payload baked into the HTML is generated before hints are computed, since hint computation requires at least one completed render to measure sizes. The server marks these trees with `InliningHintsStale`. The client immediately expires the route cache entry so that the next prefetch re-fetches the correct tree from the `/_tree` response. The segment data doesn't need re-fetching since it was already cached from the initial HTML payload. ### ISR / revalidation Hints are always available from the manifest. A missing entry is an internal error — it means the build pipeline failed to produce hints for a route that needs them. ### Fully dynamic routes at runtime No hints exist and none will ever be computed. Every segment gets `PrefetchDisabled`, which tells the client not to attempt prefetching. This avoids an infinite re-fetch loop that would occur if the client kept trying to fetch "correct" hints. ### Unified response format Also simplifies the segment prefetch response format: every response is now a `SegmentPrefetchResponse` with a top-level `buildId` and a `data` array, treating a single-segment response as a bundle that happens to have length one. This unifies the format so that bundled multi-segment responses (added in a follow-up) require no additional client parsing logic.