Audit other search-param-only navigate() calls for latent scroll-to-top bug

[chiptus]

Context

Issue #381 (scrolling the timeline sometimes scrolls the user to the top) was root-caused to src/hooks/useTimelineScrollSync.ts's debounced navigate({ to: ".", search: (prev) => ({ ...prev, scrollTo: ... }), replace: true }) call: TanStack Router scrolls window to top by default on every navigation unless resetScroll: false is passed, and this call didn't pass it.

While fixing #381, a grep for the same pattern (navigate({ to: ".", search: (prev) => ({ ...prev, ... }) }) without resetScroll: false) turned up other call sites that share the same latent defect, even though none are currently confirmed to reproduce a user-visible bug:

• src/hooks/useUrlState.ts:19-33 — generic URL-state sync hook (used broadly)
• src/hooks/useTimelineUrlState.ts:24-69 — timeline's day, time, stages, votes filter writes
• src/pages/admin/ArtistsManagement/hooks/useAdminArtistsUrlState.ts:11-13 — admin artists filter/sort state
• src/components/invite/useInviteFlow.ts:47-49 — clearing the invite search param after use

These weren't fixed alongside #381 because they're triggered by direct user actions (clicking a filter, submitting an invite) rather than a debounced background effect firing mid-scroll, so a scroll-to-top side effect there is far less likely to be noticed — but the underlying defect (missing resetScroll: false on a search-param-only replace navigation) is the same.

Task

For each call site above:

1. Check whether it can plausibly cause an unwanted scroll jump for users (e.g. does it fire while the user might already be scrolled down the page?).
2. If so, add resetScroll: false, matching the fix applied in scrollling the timeline will sometimes scroll the user to the top #381.
3. If not, note why it's safe to leave as-is.

Out of scope

Changing route-level scroll restoration config broadly, or any behavior not related to this specific resetScroll defect.