next.js

4b27fb7b - Fix an issue in how css references are collected under `next build --turbopack` (#81704)

Fix an issue in how css references are collected under `next build --turbopack` (#81704) ## Fix how client references are discovered during `next build --turbopack` To correctly serve js and css resources during server side rendering we construct a client manifest that lists all the server components and their requires resources. Prior to this PR there was a bug where we would sometimes fail to serve css resources. The cases we have seen this is when a `not-found.js` file references css that is also referenced by a layout. When present, all pages pages implicitly depend on this module and crticically depend on it as an early implicit dependency of the generated `app-page.js` file. This means if a `not-found.js` file (or another error file) would happen to depend on the same css as a normal component we would associate it as a client-reference of that component instead of any other. Then on a server side render we would simply omit it. This PR address this by ensuring we always associate client resources with _every_ server component that depends on them, not just the first one. To do this we precompute the full set of server components that depend on each client resource in the module graph and then after our dfs traversal we can collect all server components for a given entry point and then perform the association. Further more we ensure that if a resource is reachable 'directly' from the page it is associated as 'framework' dependency. This wasn't know to be an issue but it seems possible that if a conditionally rendered server component depended on a core framework dependency we might see the same problem. The downside of this approach is simply the additional 'fixed point' traversal (shared across all routes) and the slightly more complex bookkeeping during each route computation. From looking at traces building vercel-site i see that `find_server_entries` dominates the collection of client-resources (by factor of ~20, so resolving the TODO added here is probably the best approach to resolving any potential production build regressions. However, `find_server_entries` will likely still be needed in a development scenario. In either case however this is a very small part of the build taking ~20us per entry point. Fixes #77861 Fixes #79535 Fixes PACK-4282 Fixes PACK-4940