fix: prevent back-button trap on partial redirects

[bartlomieju]

Summary

Fixes back-button trap when client-side partial navigation encounters a server redirect (e.g. /docs → /docs/data-modelling/syntax). Previously both URLs were pushed to history, so pressing back would navigate to /docs which immediately redirects forward again — making it impossible to go back past the redirect.

Root cause: The click handler called maybeUpdateHistory(clickedUrl) before the fetch, then fetchPartials called maybeUpdateHistory(redirectedUrl) after — two pushState calls for a single navigation.

Fix: Remove history management from fetchPartials (it now returns the final URL) and let each caller handle history for its specific context:

Caller	Before fetch	After fetch (if redirected)
Click	pushState (clicked URL)	replaceState (swap to final URL)
Form	saveScrollPosition only	pushState (final URL)
Popstate	—	replaceState (prevents infinite loop)
Button	—	—

This also:

• Strips ?fresh-partial from URLs before they enter history (was leaking as an implementation detail)
• Uses the post-redirect URL for updateLinks(), fixing active link highlighting after redirects
• Adds saveScrollPosition() before form fetches (was previously missing — scroll was saved after DOM change)

Supersedes #3776.

Test plan

• Navigate to a page that redirects (e.g. /docs → /docs/syntax) — only final URL should appear in history, back button returns to previous page
• Normal link clicks (no redirect) — history works as before
• Form submission with POST-redirect-GET — back button returns to form page
• Back/forward to a URL that redirects — URL gets replaced, no infinite loop
• Scroll position restored correctly on back navigation
• ?fresh-partial never visible in address bar or history
• Existing partials tests pass