[Shortcut Guide] Guard against null AppWindow in SetWindowPosition

[niels9001]

Summary

Fixes the residual NullReferenceException in MainWindow.SetWindowPosition() reported in #48773 (seen on Windows 10, even after the 0.100.1 hotfix #48481).

Background

#48481 stopped the original hard crash by adding a try/catch and null-guarding App.TaskBarWindow?.AppWindow. But a second NRE remained. From the reporter's 0.100.1 log:

[Error] MainWindow.xaml.cs::SetWindowPosition::286  Failed to set Shortcut Guide window position; keeping previous layout.
System.NullReferenceException
   at WinUIEx.WindowManager.get_Height()
   at WinUIEx.WindowManager.set_MaxHeight(Double value)
   at ShortcutGuide.MainWindow.SetWindowPosition()

Root cause

Selecting the Windows section (the only common one carrying the <TASKBAR1-9> section) runs App.TaskBarWindow.Hide() → Activate() → BringToFront(). That reentrancy re-enters SetWindowPosition() while the main window's own AppWindow is transiently null. The earlier fix only guarded the taskbar window's AppWindow, not the main window's. The first size access in the method (MaxHeight = newHeight) makes WinUIEx read get_Height() on the null AppWindow → NRE. The exception is now caught (post-#48481), so it no longer hard-crashes, but the overlay is left mispositioned and the section appears broken on Windows 10.

Change

Early-return from SetWindowPosition() when the window's own AppWindow is null. This is safe: a later AppWindow.Changed / Activated event reruns the positioning once the window settles, so the final layout is still applied — only the bogus reentrant pass is dropped. The existing try/catch remains as a backstop.

Validation

• ShortcutGuide.Ui builds clean (x64 Release, exit 0).
• Opened as draft for manual repro/validation on a Windows 10 multi-monitor setup.

Notes

The long-term cleanup is the dual-window → single-overlay rewrite in #48683, which removes this code path entirely. This is the small, low-risk hotfix for the 0.100.x line.