Editable ComboBox with Fluent theme is a keyboard trap: Shift+Tab does not move focus to the previous control

### Description

When using the .NET Fluent theme (`PresentationFramework.Fluent`), an editable `ComboBox` (`IsEditable="True"`) traps keyboard focus. With focus in the ComboBox edit field, pressing **Shift+Tab** does not move focus to the previous control. Forward **Tab** works, but Shift+Tab does not, so keyboard-only users cannot navigate backward out of the control.

This is a regression/inconsistency versus the classic (Aero2) theme, where the same editable ComboBox lets Shift+Tab move focus correctly.

### Reproduction Steps

1. Create a WPF app targeting `net10.0-windows` and apply the Fluent theme by merging `pack://application:,,,/PresentationFramework.Fluent;component/Themes/Fluent.xaml` in `App.xaml`.
2. Add a window with three focusable controls in tab order: a Button, an editable ComboBox, and another Button:

```xml

```

3. Run the app. Click/Tab into the editable ComboBox's edit field.
4. Press Shift+Tab.

Also reproducible in the WPF Gallery sample: Basic Input -> ComboBox -> "An editable ComboBox" example.

### Expected behavior

Pressing Shift+Tab from the editable ComboBox edit field moves keyboard focus to the previous control (the "Before" button), matching forward Tab behavior and the classic theme.

### Actual behavior

Pressing Shift+Tab does not move focus out of the ComboBox. Focus remains trapped in the ComboBox edit field, so the user cannot navigate to the previous control using the keyboard.

### Regression?

Yes, relative to the classic (Aero2) theme. The classic theme's editable ComboBox handles Shift+Tab correctly; the Fluent theme does not. Both use the same `ComboBox` class, so the difference is in the Fluent theme's ComboBox style/template.

### Known Workarounds

Set `IsTabStop="False"` on the editable ComboBox so only its inner edit field remains a tab stop:

```xml

```

This mirrors what the classic theme does automatically and restores correct Shift+Tab navigation.

### Impact

Accessibility keyboard trap. Motor-impaired and keyboard-only users cannot navigate backward past an editable ComboBox, violating **WCAG 2.1.1 (Keyboard)** / **MAS 2.1.1**. Affects every editable ComboBox in any app using the Fluent theme.

### Configuration

- .NET version: .NET 10 (`net10.0-windows`), `Microsoft.WindowsDesktop.App` 10.0.9
- OS: Windows 11 (24H2 / 25H2)
- Architecture: x64 (not architecture-specific)
- Specific to the Fluent theme (`PresentationFramework.Fluent`); does not repro with the classic theme.

### Other information

Root cause appears to be in the Fluent theme's `DefaultComboBoxStyle`. Its `IsEditable="True"` trigger only swaps the control template and does **not** set `IsTabStop="False"` on the ComboBox:

`src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Fluent/Styles/ComboBox.xaml`
```xml

```

The classic theme sets  IsTabStop="false" in the equivalent trigger:
`src/Microsoft.DotNet.Wpf/src/Themes/XAML/ComboBox.xaml`

```xml

```

As a result, under Fluent both the ComboBox itself and its inner PART_EditableTextBox are tab stops; Shift+Tab lands on the ComboBox container, which redirects focus back into the edit field, causing the trap. Adding `` to the Fluent `IsEditable` trigger should resolve it, matching the classic theme.

Start in src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Fluent/Styles/ComboBox.xaml and compare the IsEditable trigger with the equivalent trigger in src/Microsoft.DotNet.Wpf/src/Themes/XAML/ComboBox.xaml. Reproduce the behavior in the WPF Gallery Basic Input - ComboBox editable example or the described three-control app; done means Shift+Tab moves from the edit field to the previous control under the Fluent theme.

Written by the indexing model from the issue text.