Separate route structure comparison from param comparison
Changing a page’s search params doesn’t change which page it is, but it may
change the data that page needs. The router currently mixes these concerns
by appending search params to `__PAGE__` segments. Remove that encoding so
we can compare which route is being rendered separately from the param
values used to render it.
Param values are now compared through the existing VaryPath data structure,
while route structure is compared during the existing tree traversals.
Each traversal can decide which comparisons matter for the work it’s doing.
Client-side comparisons and history restoration still need the search
params, so store them in a separate FlightRouterState slot for now. As
before, previous-page search params are stripped from normal request
headers. This is a temporary step that lets us migrate incrementally.
Eventually, FlightRouterState will be replaced by a type that represents
the route and its params more directly.
This is mostly a refactor, though it fixes an accidental inconsistency in
search-param handling compared with regular route params, avoiding some
redundant prefetch work.
Fully cached pages already track their vary params correctly. This
separation prepares us to do the same for partially dynamic segments during
navigation, so changing an unrelated param won’t require rendering their
dynamic content again.
With the route structure and the param values compared separately, a
navigation can now tell whether a segment's data has to be re-rendered at
all: `didReadChangedParam` walks the current and next vary paths in
lockstep and reads the node's `varyParams` only when a param actually
differs. A regular navigation (Default or Gesture) keeps a page or layout
whose output read none of the changed params — under a new node keyed at
the new vary path, written to the BFCache like any other — and does the
same for the head, which is keyed under its page's position and shares
data only when that position is unchanged. Refreshes still fetch, and
back/forward still restores the exact entry from the BFCache. A test
covers the head case where the metadata read searchParams but the page
did not.
