WinUI 3 RichEditBox scroll position jumps back to caret after inactive-window hover scrolling

### Describe the bug

Issue:
In WinUI 3, RichEditBox scroll position may jump back to the previous caret position after scrolling while the app window is inactive and then reactivating the window.

Steps to reproduce:
1. Open a WinUI 3 app with a RichEditBox containing long text.
2. Click inside the RichEditBox so the caret is placed on a line.
3. Scroll to a different position.
4. Click outside the app to make the window inactive.
5. Without clicking inside the RichEditBox, hover over the RichEditBox and scroll.
6. Click back into the app, even outside the RichEditBox.

Expected:
The RichEditBox should keep the current scroll position.

Actual:
The RichEditBox jumps back to the previous caret position.

Notes:
- This also reproduces in WinUI 3 Gallery.
- The issue appears related to RichEditBox / ScrollViewer focus restoration or caret bring-into-view behavior.
- Avoiding app-side Document.Selection / CharacterFormat / ParagraphFormat operations reduces additional jump cases, but this inactive-window hover-scroll case still appears to be native control behavior.

### Why is this important?

This issue affects code editors and text editing scenarios built with WinUI 3 RichEditBox.

When users scroll a long RichEditBox while the app window is inactive, the scroll position can jump back to the previous caret position after the window is activated again. This makes the editor feel unstable and causes users to lose the position they were reading or editing.

For applications that use RichEditBox as a code editor, log viewer, document editor, or long text viewer, this behavior is disruptive because users expect mouse wheel scrolling to preserve the current viewport, even if the caret remains at an earlier line.

### Steps to reproduce the bug

1. Open a WinUI 3 app that contains a RichEditBox with long text. This can also be reproduced in WinUI 3 Gallery.
2. Click inside the RichEditBox so the caret is placed on a line.
3. Use the mouse wheel to scroll to a different position.
4. Click outside the app window to make the window inactive.
5. Without clicking inside the RichEditBox, move the mouse over the RichEditBox and scroll with the mouse wheel.
6. Click back into the app window, even outside the RichEditBox.
7. The RichEditBox scroll position jumps back to the previous caret position.

### Actual behavior

The RichEditBox jumps back to the previous caret position when the app window is activated again.

### Expected behavior

The RichEditBox should keep the current scroll position after inactive-window hover scrolling and reactivating the app window. Mouse wheel scrolling should not automatically jump back to the caret position.

### Screenshots

### NuGet package version

1.8.251106002

### Windows version

Windows 11 (24H2): Build 26100

### Additional context

There is a video here to illustrate the Bug:
https://1drv.ms/v/c/12818f453d

Start by reproducing the behavior in WinUI 3 Gallery with a long-text RichEditBox, following the inactive-window hover-scroll steps. Then trace RichEditBox focus restoration and caret bring-into-view behavior; done means reactivation preserves the post-scroll viewport instead of returning to the earlier caret position.

Written by the indexing model from the issue text.