build(winui3): pin RID + flatten native DLLs into output dir

Locks RuntimeIdentifier=win-x64 so MSBuild flattens the WindowsAppSDK
native runtime files (Microsoft.WindowsAppRuntime.Bootstrap.dll +
WebView2Loader.dll, both in runtimes/win-x64/native/) directly alongside
TeamsISO.exe at build time, instead of leaving them in a runtimes/
subfolder where the loader can't find them at activation.

Also defers app.manifest from build pending the bootstrapper hardening
follow-up. WinUI 3 emits its own manifest with the DPI awareness +
supportedOS GUIDs that match what we want; reintroducing ours alongside
that needs a uap:VisualElements merge.

Build is clean. Activation still blocked on a separate WinUI 3
unpackaged-launch issue that doesn't reach Main(); diagnostics
captured in COREHOST_TRACE=1 confirm .NET host loads correctly through
CoreCLR.dll, the failure is downstream in the WinUI / WindowsAppSDK
activation path.

The WPF host remains the running build until the activation issue is
resolved.

src/TeamsISO.App.WinUI/TeamsISO.App.WinUI.csproj

@@ -55,6 +55,14 @@
       Main and calls Bootstrap.TryInitialize(0x00010006) before Start.
     -->
     <DefineConstants>$(DefineConstants);DISABLE_XAML_GENERATED_MAIN</DefineConstants>
+    <!--
+      RuntimeIdentifier locks the build to win-x64 so runtime DLLs from
+      runtimes/win-x64/native (Microsoft.WindowsAppRuntime.Bootstrap.dll,
+      WebView2Loader.dll) flatten into the output dir alongside the .exe.
+      Without this, those DLLs sit in runtimes/win-x64/native/ and the
+      loader doesn't find them at activation time.
+    -->
+    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
     <Nullable>enable</Nullable>
     <ImplicitUsings>enable</ImplicitUsings>
     <ApplicationIcon>Assets\teamsiso.ico</ApplicationIcon>