TabItem.OnPreviewGotKeyboardFocus causes StackOverflowException when ancestor redirects focus

# TabItem.OnPreviewGotKeyboardFocus causes StackOverflowException when ancestor redirects focus

## Summary

`TabItem.OnPreviewGotKeyboardFocus` can enter infinite recursion and crash with a `StackOverflowException` when an ancestor element's `GotKeyboardFocus` handler redirects keyboard focus back to the `TabItem`.

## Observed behavior

- Application crashes with `StackOverflowException` on the UI thread when a tool window tab receives keyboard focus.
- The call stack shows ~90+ recursive frames cycling through `TabItem.OnPreviewGotKeyboardFocus` → `MoveFocus` → `ChangeFocus` → `GotKeyboardFocus` → ancestor handler → `Keyboard.Focus(tabItem)` → `TryChangeFocus` → `PreviewGotKeyboardFocus` → back to `OnPreviewGotKeyboardFocus`.

## Repro notes

1. Host a `TabControl` inside a container that has a `GotKeyboardFocus` handler which redirects keyboard focus to a `TabItem` when the tab content receives focus.
2. Switch tabs (or trigger any action that calls `TabItem.SetFocus()`).
3. The `MoveFocus` call in `OnPreviewGotKeyboardFocus` moves focus to the tab's content, which fires `GotKeyboardFocus` on the content. This event bubbles to the ancestor handler, which redirects focus back to the `TabItem`, re-entering `OnPreviewGotKeyboardFocus`.
4. The cycle repeats until the stack overflows.

This pattern occurs in Visual Studio integration scenarios where pane hosting infrastructure participates in focus management.

## Impact

Any WPF application hosting a `TabControl` inside a container that redirects `GotKeyboardFocus` back to tab headers is affected. The crash is deterministic and unrecoverable.

## Expected behavior

`OnPreviewGotKeyboardFocus` should handle re-entrant calls gracefully without infinite recursion.

## Actual behavior

Infinite recursion → `StackOverflowException` → process crash.

## Suspected root cause

The focus-into-content logic added by #8300 (for #8293) runs the `MoveFocus` call unconditionally — even when the tab is already selected. The original code ran `MoveFocus` inside the `!IsSelected` branch, where re-entrancy couldn't occur because the tab would already be selected on the second pass. The new code path has no such protection.

## Proposed fix direction

- Add a `MovingFocusToContent` re-entrancy guard flag (following the existing `SettingFocus` pattern in `BoolField`) around the `MoveFocus` + `SetFocusedElement` block.
- When `OnPreviewGotKeyboardFocus` is re-entered while the flag is set, skip the entire focus-to-content block, breaking the cycle.