test: lock client-router query-string preservation on every nav path

[vivek7405]

Closes #639

Query params sometimes appeared NOT to carry forward while dogfooding the blog. A source review of packages/core/src/router-client.js found the router mostly correct: finalUrl defaults to the full link href (so pushState keeps the query), the snapshot + prefetch cache key on pathname + search (so ?x=1 and ?x=2 are distinct), and the GET-form url.search = '' rebuild is the spec-compliant HTML5 behaviour. So this is primarily locked browser coverage that will ALSO surface any genuine drop.

What it adds

packages/core/test/routing/browser/query-params.test.js (real browser, all three wtr engines):

• a link with a query preserves it in location.search AND in the URL the router fetches;
• sequential navs keep DISTINCT params (/a?x=1 then /b?y=2 lands ?y=2, not merged, not dropped);
• the prefetch cache is keyed by search (a different / absent search value is a cache MISS);
• back/forward restores the prior entry's query string;
• a GET-form submission REPLACES the action's query with the form fields (spec-correct, asserted so it is not later "fixed" into a regression);
• a server redirect updates the URL to the redirect target's query;
• (from a Next.js / Remix cross-check) repeated keys ?foo=bar&foo=baz stay a DISTINCT cache key from the single-value form (WebJs keys on the raw pathname+search, so it does not collapse them the way Next's #92787 bug did); a hash + a query survive a nav together and a hash change does not drop the query; an encoded / unicode query value round-trips.

Result: all nine cases pass on Chromium, Firefox, and WebKit, so no genuine query-string drop exists in the current router. No source change was needed.

Definition-of-done surfaces

• Tests (browser): the new file (the headline layer for a client-router behaviour). Counterfactuals to follow in the PR.
• Docs: N/A because no behaviour changed, and the one deliberate case (GET-form replaces the action query) is already documented accurately in agent-docs/advanced.md ("Form submissions", the GET bullet).
• Source / scaffold / MCP / editors / bun-parity: N/A because this is a test-only change (no packages/*/src, no generated-app or editor surface).

Test plan

• All 9 cases pass on all three browser engines
• Counterfactuals: reverting finalUrl-keeps-search / the GET-form reset / the cacheKey search each reds the matching case (see the counterfactual comment)
• Cross-checked against Next / Remix; added repeated-keys, hash+query, and encoded-value cases

[vivek7405]

Counterfactual proof: the lock has teeth (all three router mechanisms)

Since this is a coverage-lock PR, I confirmed each assertion actually fails when the router line it guards is broken. Three source reverts cover all six cases (each run on Chromium + Firefox + WebKit):

• Drop the search from cacheKey (u.pathname + u.search -> u.pathname): only the prefetch-keying case reds (the ?x=2 / query-less peek starts HITTING the ?x=1 entry). 5 pass, 1 fail.
• Remove the GET-form url.search = '' reset: only the GET-form case reds (?old=1 is no longer replaced, it merges with the form fields). 5 pass, 1 fail.
• Strip the search from finalUrl (the history URL): the nav-preserve, sequential, back/forward, and GET-form location.search cases all red (4 fail), while prefetch-keying and redirect stay green (redirect overwrites finalUrl with resp.url, prefetch does not use finalUrl).

So the six cases genuinely exercise the three distinct query paths (history URL, cache key, form-submission reset), not just a happy path. No source change was needed: the router already preserves query strings correctly on every path, which is what the review found and this pins.

[vivek7405]

Checked each case against the router source to make sure none pass vacuously. The prefetch-keying case genuinely populates the cache (swapBody has a text/html 200 so it reaches prefetchStore) and the ?x=2 / query-less peeks miss only because cacheKey is pathname+search. The back/forward case asserts ?y=2 before history.back() so the ?x=1 restore is a real popstate observation, not a pre-set value. The redirect case's defineProperty shadows the Response getters and drives the finalUrl=resp.url branch. Isolation holds: teardown restores fetch + replaceState(before) + _resetPrefetch, and each test pushes its own entries before going back. The GET-form action really carries ?old=1 so the replace assertion has teeth. Nice and tight.

[vivek7405]

Reworked the GET-form case to poll location.search (which settles after the fetch -> swap -> pushState chain) instead of a fixed delay, so it can't flake on a slow runner and the fetched-call lookup is guaranteed present by the time search settles. Re-ran the whole suite several times across the three engines, 9/9 every time. Nothing else moved.

[vivek7405]

Added the Turbo GET-form parity case (a GET form must not merge the current page's query into the submission) after cross-checking against the Turbo router this is derived from. It resolves the absolute action path against location.href, which drops the page's ?sort=old before the form fields set the search, so ?q=new wins. The find() filters on q=new so it doesn't pick up the earlier navigate() fetch of the same path. Ten cases now, stable across the three engines.