Re-implement Remix's "seen routes" cache in lazy route discovery for Framework Mode

[rossipedia]

As mentioned in #11977, I'm proposing that the discoveredPaths mechanism be brought back into react-router for Framework Mode, to avoid making excessive __manifest calls in the presence of dynamic path segments.

One of the approaches that we use a lot is debouncing via clientLoader, and a lot of those implementations use a fetcher that targets routes that have dynamic path segments. Without this cache of seen/resolved routes, this ends up creating a lot of unnecessary __manifest fetches:

Screen_Recording_2025-06-27_at_6.41.07_PM.mp4

Discussing this on Discord with @brophdawg11, the proposed implementation would look something like this:

patchRoutesOnNavigation({
  path,
  matches,
  fetcherKey,
  patch,
  // proposed: opt-into the behavior we removed in #11977
  bikeshed_markPathAsFinalAndDontFetchAgain,
})

ie: an additional parameter to patchRoutesOnNavigation() that would add the resolved routes to the "resolved" cache and prevent future manifest requests. This parameter could be leveraged by Framework Mode, as it would know ahead of time what the available finite set of routes is.

[brophdawg11]

Adding some related context:

• When using lazy route discovery, if a client matched route has a dynamic segment, we have to still check with the server because there could be a higher-scoring route with a static segment that we don't yet know about
• Framework mode keeps a cache of previously discovered paths to prevent re-fetching of the same path in the future
• At one point we moved this logic into the router itself but had to remove it because it was overly restrictive for some advanced data mode use cases

When we had the cache inside the router it applied to any router operation, but when it lives in the framework mode internal hook it's only applying to declarative Link/NavLink but not imperative navigate/fetcher calls. This proposal would move it back to the router in an opt-in way so framework mode could opt into caching for imperative calls and also give data mode users a way to opt in

[brophdawg11]

Nevermind - this was a misunderstanding on my part. It turns out we just never cherry pick'd the fix we made in v6 to v7 so v7 just had a regression - fixed in #13911