render global error for failed cache regeneration

[Swpn0neel]

summary

so we were using use cache for a static app router, and nextjs was storing the generated page to serve later reqs quickly. if that cache was invalidated, the next request was regenerating the page.

currently, for an uncaught rendering during the regeneration, the error escapes the app rendering system and returns a plain-text internal server error. since the response is no longer a regular nextjs html document, the browser cannot load and display the app’s global-error.tsx component.

so, my change detects that rendering failure and renders the current request through an existing dynamic error handling path that gives react the chance to prepare an error response and letting the browser display the app's custom error screen.

why

a failed page should never be written to the router cache, otherwise nextjs will accidentally serve the error screen as the real cached page to later visitors.

the existing static regeneration process already prevents the failed page from being cached. this change keeps that behavior by only creating a dynamic error response for the visitor whose request triggered the failed regeneration.

the response still uses a 500 status because the page failed to render and it is also marked as a cache miss and receives private no-cache headers, so the error response cannot replace the valid cached page.

and also, the recovery is limited to digested react rendering errors from static routes with a cache key, and it does not change nofallback behavior, cache infrastructure errors, or responses that have already started sending data.

testing

i have added a new production regression test that verifies whether:

• the page is generated successfully during the production build

• its use cache entry can be invalidated

• failed regeneration returns a 500 html response instead of plain text

• the response is marked as a cache miss and cannot be cached

• the browser hydrates and displays the custom global-error.tsx component

and this focused production test passes with both turbopack and webpack.

also, the next.js package type check, focused eslint check, prettier check, and git diff --check also pass.

fixes #96567

[Swpn0neel]

@ztanner @eps1lon, could you please review this when you have time? it changes the app-page runtime around static cache regeneration and error handling. the focused production regression passes with both turbopack and webpack. thank you.