Intercepting Routes Fail After Full-Page Navigation In Production Due To Cached CouldBeIntercepted Flag

Static prerendering bakes couldBeIntercepted: false into the RSC payload because setVaryHeader() has not been called yet when getRSCPayload() reads ctx.res.getHeader('vary'). In app-render.js, the couldBeIntercepted calculation relies on the Vary: next-url header, but during build-time static generation this header is absent, leading to the flag being falsely false. This incorrect value is then used by the client-side optimistic router to decide that the route is not interceptable.

1. Clone the reproduction repository and install dependencies. 2. Run `npm run build && npm start`. 3. Open http://localhost:3000 and click 'Login (router.push)' → modal appears (interception works). 4. Navigate directly to http://localhost:3000/login via browser URL bar → full page (correct). 5. Click 'Other Page' to return to '/'. 6. Click 'Login (router.push)' again → full page is shown instead of modal.

This fix may interfere with other middleware or CDN layers that rely on the Vary header. Manually setting the Vary header could override existing values if not merged correctly, potentially breaking cache partitioning or causing unexpected cache hits/misses. In multi-threaded or concurrent rendering scenarios, header mutations might race. If the fix causes issues, rollback by reverting the app-render.js changes and instead move the setVaryHeader call in base-server.js earlier (before renderToHTML) to avoid duplicate header setting. Additionally, verify that the Vary header is only set for routes with interception routes to avoid unnecessary cache partitioning for all static pages.