fix PPR navigations when visiting route with seeded cache (#67439)
During SSR, we walk the component tree and pass and immediately seed the
router cache with the tree.
We also seed the prefetch cache for the initial route with the same tree
data because navigations events will apply the data from the prefetch
cache. The rationale for this is that since we already have the data, we
might as well seed it in the prefetch cache, to save a server round trip
later.
The way we're seeding the cache introduced a bug when PPR is turned on:
PPR expects that each element in `FlightDataPath` is of length 3,
corresponding with: `[PrefetchedTree, SeedData, Head]`. However, we were
seeding it with 4 items: `[Segment, PrefetchedTree, SeedData, Head]`.
When the forked router implementation sees anything other than 3 items,
it reverts back to the pre-PPR behavior, which means the data will be
lazy-fetched during render rather than eagerly in the reducer.
As a result, when navigating back to the page that was seeded during
SSR, it wouldn't immediately apply the static parts to the UI: it'd
block until the dynamic render finished.
This PR also includes a small change to ensure reused tasks don’t
trigger a dynamic request. A navigation test was failing because this PR
fixed a bug that was causing it to hit the non-PPR behavior, which
already handles this correctly.
I've added an explicit test for this in PPR. I've also excluded all of
the `client-cache` tests from PPR, as many of them were already failing
and aren't relevant to PPR, since PPR doesn't currently make use of the
`staleTime`/ cache heuristics that the regular router does.