The selected category is not persisted across page loads

Is your feature request related to a problem? Please describe.
When a user selects a category, it is only maintained in-memory. It isn't stored in the URL and isn't persisted anywhere else. The symptom is that the category resets to "All notes" on every page load and when the app is loaded fresh.

However, the filtering works. getFilteredNotes() does filter by the category the user selects and changes the sorting from "most recent" to the selected category. But any refresh changes the view back to "most recent" in the notes list and doesn't retain the selected category. For users who work in a particular category, it means continually clicking back to that category.

Also, browers back/forward navigation doesn't navigate between categories.

Describe the solution you'd like
There are two parts to the feature and each could land independently:

1. Store the selected category in the URL so the category remains selected when the page reloads or the user uses the back/forward navigation in their browser or shares a link
2. Use a user setting to restore the category the user selected last when the app loads. This would be similar to how the last-viewed note is loaded using loadRecentOnStartup and notesLastViewNote. Part 1 by itself doesn't cover what is likely the common use case of opening Notes from the app menu. It lands on /app/notes with no query string so the user has to navigate back to the category they had navigated to last time they were in the app.

Describe alternatives you've considered
For the first item, I considered a path segment (/category/:category/) but the categories are stored as folder paths containing the forward slash. This would make the wildcard route ambiguous vis-a-vis the existing /note/:noteId. It would also break existing note URLs. Using a query param avoids these problems while encoding the slashes properly and matching the current ?new convention.

For the second item, I considered browser storage as a simpler option but the app doesn't currently use that. So we went with the approach that notesLastViewedNote already uses. Also, this approach allows for syncing across devices.

Additional context
Issue #1079 talks about persisting the visibility of the navigation itself. While this is a different setting, it does address the same underlying gap as this request. #879 which is about the category tree (something else I'm very keen on addressing) would also need persistence so creating the foundation here would be beneficial to other features that would need the same persistence mechanism.

Here are some open questions:

1. Should I use the query parameter as I suggest or the path segment for the category in the URL?
2. How should the URL represent "Uncategorized" (which is an empty string and a real category) from "All Notes" which is a null category. Right now, these are distinct states and naive encoding wouldn't distinguish between them.
3. Should restoring the category on startup be a new setting or should it be folded into the existing loadRecentOnStartup setting?
4. If item 2 restores the category on startup, should this be reflected in the URL as well so the URL has the actual category state? I think this is a good design choice but want to confirm first.

_{Investigated with the help of Claude Code.}

Start at the notes view around getFilteredNotes(), the /app/notes entry point, and the existing loadRecentOnStartup and notesLastViewNote behavior. Trace how the selected category and current URL are handled, then resolve the open questions about query-state encoding, startup restoration, and URL synchronization with maintainers. Done means refreshes, shared links, browser back/forward navigation, and fresh app starts preserve the intended category without confusing All Notes and Uncategorized.