[cre8ive-marketing]

What does this change?

Fixes two bugs on Settings → Donut toolbar, both reported by @adnan-bhaldar:

Issue	What was wrong	What changes
#425 "Donut Toolbar Count display only reflects the front donut"	The badge next to each profile counted only the front face's slices. A donut with a back face (most built-in ones since schema 30) showed a number that didn't match what it holds.	ProfileItemViewModel.Count shows the back face too when it has slices: 10 · 9. A donut without a back face still shows one number, as before. The badge's tooltip (CountTip) names the faces, using the existing toolbar.face_front / toolbar.face_back strings, so there are no new UI strings: "Front 10 · Back 9". It updates with every change through Refresh, like the old count.
#427 "Donut Toolbar Search Missing clear button and search state persists on profile switch"	(1) The search boxes had no button to clear them. (2) Text typed in the Available presets search stayed after choosing another donut, which hid most of that donut's presets.	(1) Every search box (Classes="search": Donut toolbar ×2, Presets page, Home) gets Fluent's clearButton class: an × appears in a focused box with text. (2) OnSelectedProfileChanged clears PaletteSearch, as AddGroup already did. The profile list's own search is left alone, because it filters the list being clicked.

No settings schema change, and no overlap with my other open PRs (#349, #351, #393, #401, #429, #432).

How was it tested?

• dotnet format --verify-no-changes
• dotnet test with FFmpeg 9.0.2 and rhwp 0.8.7: Platform 48, Core 454, Cli 27, Setup 145, Engines 1460, App 809 pass, none fail.
• New tests in ToolbarEditorTests.cs (ToolbarPageTests):
  • A_profile_counts_both_faces_and_switching_profiles_clears_the_preset_search:
    • "3 · 1" and its tooltip; "3" with an empty back face;
    • the preset search is empty and the whole palette is visible after switching donuts.
  • Search_boxes_have_a_clear_button: both search boxes on the page have the class, the × is visible in the focused box with text, and it saves the screenshot below.
• Two existing tests (A_new_group_heads_the_available_presets_and_every_profile_count_stays_right, Reset_puts_a_built_in_profile_back_and_the_list_follows) compared the badge with the front count only. They now expect front · back.

Screenshots (UI changes)

Both faces counted in the profile list, and the × in the preset search (from the new test):

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files (none added; the tooltip reuses Front / Back)
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md (none)

Fixes #425. Fixes #427.

[KnifeLemon]

Thanks @cre8ive-marketing. Both fixes are small and to the point: the badge shows the back face only when there is one, the tooltip reuses the existing Front/Back strings, Fluent's clear button needs no new code, and clearing the palette search on a profile switch matches what AddGroup already does. I ran the ToolbarPage tests locally and they pass.

One small thing we may tidy when merging: for a donut without a back face the tooltip reads "Front 3 · Back 0"; just "Front 3" would match the badge. CI for fork runs is waiting for approval; we'll start it and merge once it's green.