Improve Query Parameter Consistency and State Persistence Across Navigation

[seanes]

Description

Navigation with query parameters is inconsistently handled, leading to various issues (cf. #1298, #1244, and #1314). These issues may also impact #1304 and #1315.

Proposed Solution

1. Centralize Hydration and Rehydration State from Query Parameters

• Persist the state of filters, search queries, sort order, and selected party in the URL as query parameters. Ensure these states are also read from the URL when loading a page.
• Use the URLSearchParams API to manage query parameters uniformly through a utility function.
• Exclude party from query parameters if party.type = person, until person IDs are masked.

2. Use Query Parameters Contextually

Retain only relevant query parameters when navigating between routes. For example, navigating from /?party=PARTY_URN&search=hello to /saved-searches should keep party=PARTY_URN, but discard search=hello.

3. Improve Handling for Page Refreshes and Back Navigation

• Refreshing should preserve filters and selected party where possible, while invalid filters should be removed from the URL.
• Update the URL with every applied filter, but replace the current state rather than pushing it to browser history. This means: Navigating back should go to the previous route, not previous filter states. For instance:

1. User is at / (inbox).
2. User navigates to /drafts.
3. User applies filter A => URL updates to /drafts?filterA=valueOfFilterA.
4. Additional filters update the URL but do not affect the back navigation, which would return to /.

Benefits

• User Experience: Consistent handling of query parameters will make navigation more predictable for users, reducing confusion and improving usability, especially during page refreshes or when using the back button.
• State Persistence: Preserving filters, search queries, and selected entities in the URL means users can share or bookmark specific views, enhancing accessibility and making the app more user-friendly

Complexity that makes the design brittle or hard to implement should be avoided in favor of a robust solution.

This should be thoroughly tested through Playwright tests.

Additional Information

No response

### Tasks
- [x] fix: improve query parameter consistency and state persistence across navigation
- [x] https://github.com/digdir/dialogporten-frontend/issues/1347
- [x] https://github.com/digdir/dialogporten-frontend/issues/1346
- [ ] https://github.com/digdir/dialogporten-frontend/issues/1355

[seanes]

@LeifHelstad @mbacherycz Thoughts on this?

[LeifHelstad]

• Searches should be built and stored in one common way, regardless of person or organisation ** This means that "party" should also be part of url an search for person as well

• This social security number must not be used as "party" for more than one reason Primarily, the social security number (SSN) should be exposed as little as possible The SSN is not a static value Foreigners with a D-number (+40 on days) as SSN will have this replaced with a birth number as SSN over a few years Having a legal gender change forces the replacement of the third digit in the social security number part of the SSN

[LeifHelstad]

Jeg ser på denne som en "feature" der alle "Stories" (#1346, #1347, #1355) er levert og testet i sprint 10. Siden alle Stores er testet OK anser jeg Featuren som helhet også som OK. Test passed.