TitleBar: avoid AppWindow.Title() getter reads that can fail-fast the process (#11214)

[crutkas]

Draft / discussion — a WinUI-side mitigation for #11214. Not yet built/validated locally; opening to discuss the approach.

Problem

TitleBar::UpdateTitle and TitleBar::ResetTitle read back AppWindow.Title (three getter calls) to capture/restore a "default" window title and to skip redundant sets. During a deferred layout pass at startup, that getter can fault inside the windowing layer when the native window title is momentarily empty, terminating the process with an E_INVALIDARG (0x80070057) fail-fast. Full root cause in #11214.

A try/catch in the control cannot help here — the failure is a fail-fast inside the windowing callee, not a returnable HRESULT — so the only WinUI-side mitigation is to not perform the getter reads.

Change

• UpdateTitle: set AppWindow.Title unconditionally; stop reading it back (removes both the default-capture read and the redundant-set read).
• ResetTitle: no longer reads AppWindow.Title, and no longer auto-restores a previously-captured window title.
• Remove the now-unused m_defaultAppWindowTitle / m_hasDefaultAppWindowTitle members.

Tradeoff (why this is a draft)

This drops the automatic "restore the window's original title when TitleBar.Title is cleared" behavior. Apps that relied on it would set Window.Title / AppWindow.Title themselves.

The preferred fix is in the windowing layer — make the AppWindow.Title getter treat an empty title as valid (it's a wrapper over GetWindowTextLengthW, which returns 0 for an empty title and does not reset the last-error). This PR is a middle-layer mitigation for discussion: should WinUI take it in the meantime, or rely solely on the platform fix?

Related app-side workaround: microsoft/PowerToys#49069.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com