Clarify Window.Activate foreground behavior

[JesseCol]

This is from JeCollin's AI assistant. AI makes mistakes.

Summary

• Clarifies that Window.Activate attempts to activate the window, but doesn't force a background app into the foreground.
• Aligns the wording with the Win32 SetActiveWindow docs, including the calling thread message queue requirement and foreground app behavior.

Source

• https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-setactivewindow

[GrantMeStrength]

The core intent is right — the current description overclaims by saying Activate brings the window to the foreground unconditionally, and that deserves a fix. But the proposed wording directly transplants Win32 SetActiveWindow semantics in a way that doesn't fit the WinUI 3 abstraction level.

Specific issue: "The window must be attached to the calling thread's message queue."

This clause doesn't belong here. A Microsoft.UI.Xaml.Window object is already bound to its dispatcher/UI thread — callers don't manage message queue attachment. If you call Activate() from the wrong thread you get a thread-affinity exception, not the silent failure this clause implies. It's a Win32 implementation detail that shouldn't surface at the WinUI 3 API level.

The "If the app is in the foreground when the *system* activates the window" phrasing is also a bit circular when used inside a description of what this method does.

Suggested replacement description:

Attempts to activate the application window. If the calling app is in the foreground, the window is brought to the foreground (top of Z-order) and receives input focus. If the app is in the background, this method does not force the window into the foreground.

This keeps the valuable clarification (foreground restriction) without the Win32 message-queue clause.

[GrantMeStrength]

@copilot /review

[GrantMeStrength]

Review: Concerns

This PR adds Win32-specific language (message queues, Z-order, foreground window behavior) to the WinUI Window.Activate documentation. While technically accurate, WinUI documentation should be accessible to developers who may not have Win32 background.

Consider:

• Using WinUI/UWP-style terminology where possible
• Moving detailed Win32 interop behavior to a Remarks section rather than the primary description
• Linking to the Win32 SetForegroundWindow docs for readers who want the full platform details