refactor: Move most CardBrowser methods to CardBrowserFragment

[david-allison]

When I was looking into

• Card Browser: Migrate to Material 3 SearchView #18709

I found that I wanted to:

1. Move the menu state to a ViewModel
2. Split the ViewModel into a Fragment-level, and an Activity-level ViewModel
   • When we added the NoteEditor ([GSoC'24] Add NoteEditor to CardBrowser #16764 ), a lot of bugs were introduced due to the complexity
   • The panes are an activity-level concern, and would be easier to focus on with a smaller class
   • Most of the rest of the logic is CardBrowserFragment-based
3. Introduce the SearchBar/SearchView

These changes have been done on a branch for (1) and (3), but it feels like a 'huge' functional chance that I'll struggle to get reviewed with the Browser in its current state.

This PR moves us closer to (2), and closer to:

• a separation of concerns, adding in a CardBrowserFragmentViewModel
• splitting out a PR of (1) - as it would move the menu state into the future CardBrowserFragmentViewModel

Fixes

• Migrate the Browser into a Fragment #17901 (follow-on)

Approach

• Go through method by method and move them to the fragment
• Once a sufficient number of methods were moved, move both onKeyUp and onOptionsItemSelected for these methods into the CardBrowserFragment, removing

How Has This Been Tested?

CI

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[BrayanDSO]

Nice movement

[mikehardy]

nice