Summary of the Pull Request

Windows App SDK 2.3 is the latest stable release and includes new optional WinUI/XAML performance paths. This PR upgrades PowerToys' centrally managed Windows App SDK dependency set and the standalone Command Palette extension template from 2.2 to 2.3.1.

The package bump alone did not produce a statistically measurable Settings startup improvement. Holding Settings open for five seconds after first visibility showed a non-conclusive 2.28% CPU reduction and no working-set change, with a small 0.30 MB private-memory increase. The optional XAML changes also did not improve Settings startup or CPU conclusively, but reduced its settled working set by about 1.8 MB; those behavior changes are intentionally not enabled in this dependency-only PR.

PR Checklist

• Closes: N/A
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Existing representative targets build successfully; no test-code changes were needed for this dependency update
• Localization: All end-user-facing strings can be localized (N/A: no end-user-facing strings changed)
• Dev docs: Added/updated (N/A: no developer documentation behavior changed)
• New binaries: Added on the required places (N/A: no new binaries were added)
  • JSON for signing for new binaries (N/A)
  • WXS for installer for new binaries and localization folder (N/A)
  • YML for CI pipeline for new test projects (N/A)
  • YML for signed pipeline (N/A)
• Documentation updated: N/A; no user-facing behavior or documentation changed

Detailed Description of the Pull Request / Additional comments

Updates the dependency set required by Windows App SDK 2.3.1:

• Microsoft.WindowsAppSDK: 2.2.0 -> 2.3.1
• Microsoft.WindowsAppSDK.Foundation: 2.1.0 -> 2.3.5
• Microsoft.WindowsAppSDK.AI: 2.2.3 -> 2.3.4
• Microsoft.WindowsAppSDK.Runtime: 2.2.0 -> 2.3.1
• Command Palette extension template Microsoft.WindowsAppSDK: 2.2.0 -> 2.3.1

The resolved graph uses WinUI 2.3.0. The four separately tested XAML opt-ins (DefaultStyleOptimizations, DeferContextFlyoutInit, IconNoGridOptimization, and OptimizeApplyStyles) are not enabled here. Their app-dependent results suggest that enabling them should be evaluated separately with scenario-specific profiling rather than bundled into the dependency upgrade.

Validation Steps Performed

• Built x64 Debug Settings UI, native Runner, Image Resizer's AI consumer, Command Palette extension template, and Environment Variables.
• Built distinct self-contained x64 Release binaries and verified that the Windows App SDK 2.2.0 and 2.3.1 outputs contained different WinUI binaries.
• Each comparison discarded three warmups and used 100 paired launches with alternating A/B order.
• Environment Variables first-visible-window measurements:
  • 2.2.0 -> 2.3.1 default: -0.34% geometric startup delta, 95% bootstrap CI -1.45% to +0.77%; no statistically measurable gain.
  • 2.3.1 default -> four optional XAML changes: -5.57% startup, 95% bootstrap CI -6.71% to -4.49%, with CPU -5.14%, working set -1.85%, and private memory -4.40%.
• Settings Dashboard five-second measurements:
  • Every instance remained alive, visible, and responsive for five seconds after first visibility; all 200 measured launches in each comparison succeeded.
  • 2.2.0 -> 2.3.1 default: startup -0.71% (95% CI -3.26% to +1.76%); CPU consumed during the five-second hold -2.28% (95% CI -4.68% to +0.20%); settled working set +0.33% (95% CI -0.25% to +0.88%); settled private memory +0.27% (95% CI +0.13% to +0.41%, about +0.30 MB). Startup, CPU, and working-set changes were not statistically conclusive.
  • 2.3.1 default -> four optional XAML changes: startup +0.99% (95% CI -1.50% to +3.69%); CPU consumed during the hold -1.69% (95% CI -3.72% to +0.44%); settled working set -0.72% (95% CI -1.23% to -0.23%, about -1.80 MB); settled private memory -0.13% (95% CI -0.27% to -0.003%, about -0.15 MB). Only the small memory reductions were statistically measurable.
• Settings was launched through its Runner argument contract with a live parent PID and unique pipe names so the Release build exercised OnLaunchedFromRunner instead of redirecting or exiting. Readiness required a nonzero visible main window, followed by the five-second residency period before settled CPU and memory sampling.

The optional XAML changes were enabled only in temporary benchmark builds and are not part of this PR.