Back/forward to an evicted same-route entry that differs only in search params leaves the wrong page on screen #1030

Problem

Going back or forward to a history entry on the SAME route that differs only in search params, after that entry was evicted from the client's history cache, commits no tree. The URL and the entry's location state change, but the page on screen stays the one the user left.

This is the load-more pattern (?page=N) once the list is longer than the history cache: the user presses Back and sees the wrong page's items.

Found while fixing #1029; reproduced on main (eed288b1) by the e2e written for that fix, which had to evict through another route to avoid it.

Expected vs actual

A cached entry, and an evicted entry on a different route, restore correctly.

Where

Traced by reading; the cause is not confirmed by a failing unit test yet.

• packages/rangojs-router/src/browser/partial-update.ts (around lines 229-248): previousUrl prefers tx.currentUrl, which on a traversal is already the target URL (src/browser/navigation-transaction.ts, around line 132; the comment near partial-update.ts:244 acknowledges it). The server is then told the client is already on the target, so the partial response reuses every segment.
• packages/rangojs-router/src/browser/partial-update.ts (around line 501): with nothing to render, the transaction commits without a tree.
• packages/rangojs-router/src/browser/navigation-transaction.ts (around line 193): that commit still delivers the entry's location state.

Notes

• Same family as useLocationState shows the destination entry's state before the destination tree commits (load-more duplicates items while a navigation is pending) #1029: the displayed entry is updated in pieces at different times.
• The skill says back/forward restores "cached or refetched" entries; this case is neither.