TabView TearOutTabs: Visual artifacts are generated immediately after TabTearOutWindowRequested is raised

### Describe the bug

A new window is returned to the tear out code by the `TabTearOutWindowRequested` event handler. This window is then shown before being immediately hidden and it's z order changed (presumably behind the original window). I'm not sure what's causing the window to be shown, although it is being activated as well.

In a packaged app this results in noticeable flickering, the window glow border switches on and off and the apps task bar icon animates (at least on win 11).

In an unpackaged app in addition to the above, showing a new window for the first time triggers a window entrance animation. The animation lasts approximately half a second, both defeating the immediate hiding of the new window and making the entire feature unusable. See the giff below.

It would be even worse in the repero app if I hadn't added code to limit the number of new windows created in the TabTearOutWindowRequested event handler.

Repro project: [TearOutTabs.zip](https://github.com/user-attachments/files/17715511/TearOutTabs.zip)


### Steps to reproduce the bug

.

### Expected behavior

The window shouldn't be made visible.

### Screenshots

_No response_

### NuGet package version

WinUI 3 - Windows App SDK 1.6.1: 1.6.240923002

### Windows version

Windows 11 (22H2): Build 22621

### Additional context

_No response_

Start with the attached TearOutTabs.zip repro and the TabView tear-out path around the TabTearOutWindowRequested event, comparing packaged and unpackaged behavior on Windows 11. Reproduce the first-window flicker and entrance animation; done means the returned window is not visibly shown, activated, or animated before the tear-out flow completes.

Written by the indexing model from the issue text.