build(winui3): suppress UndockedRegFreeWinRT auto-init; document chase

Adds <WindowsAppSdkUndockedRegFreeWinRTInitialize>false</...> with a
comment chain that traces the runtime activation failure investigation
to the next maintainer:

1. WindowsAppSDK's UndockedRegFreeWinRTCommon.targets only auto-enables
   the ModuleInitializer when WindowsAppSDKSelfContained=true.
2. Without it, framework-dependent unpackaged builds need our own
   explicit Bootstrap.TryInitialize call (Program.cs already does this).
3. WITH it, the bundled auto-init P/Invokes Microsoft.WindowsAppRuntime.dll
   during module load — but the runtime DLL lives in the framework MSIX
   package, not the output dir, and Bootstrap hasn't yet added the
   framework dir to the DLL search path. The P/Invoke fails and the
   .exe dies before Main runs.

Setting the property to false explicitly suppresses the early P/Invoke
so our Program.Main + Bootstrap.TryInitialize can sequence correctly.

This didn't fix activation on this build host though — the .exe still
shows "this application could not be started." Strong suspicion: the
managed assembly references Microsoft.WinUI.dll which itself has
DllImport-style dependencies the .NET host probes during assembly load.

Recommended next steps (not done overnight to avoid further blind
swings): attach a debugger to TeamsISO.exe before Main runs (windbg
sxe ld for the runtime DLL, or VS 'Just My Code: off' attach), capture
the CLR fusion log, or try a known-good Microsoft WinUI 3 template
side-by-side to isolate whether the issue is project or machine.

Build remains clean. WPF host unaffected.

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

@@ -63,6 +63,19 @@
       loader doesn't find them at activation time.
     -->
     <RuntimeIdentifier>win-x64</RuntimeIdentifier>
+    <!--
+      Suppress the auto-injected UndockedRegFreeWinRT ModuleInitializer.
+      The bundled initializer P/Invokes Microsoft.WindowsAppRuntime.dll
+      during module load, BEFORE our Program.Main has a chance to call
+      Bootstrap.TryInitialize. Since the runtime DLL lives in the framework
+      MSIX package (not the output dir) on a framework-dependent install,
+      the P/Invoke fails to locate it and the .exe dies with the generic
+      "this application could not be started" dialog — diagnosed by
+      following the Microsoft.WindowsAppSDK.UndockedRegFreeWinRT.CS.targets
+      chain and reading the auto-init source. Our Program.cs handles the
+      bootstrap explicitly in the right order.
+    -->
+    <WindowsAppSdkUndockedRegFreeWinRTInitialize>false</WindowsAppSdkUndockedRegFreeWinRTInitialize>
     <Nullable>enable</Nullable>
     <ImplicitUsings>enable</ImplicitUsings>
     <ApplicationIcon>Assets\teamsiso.ico</ApplicationIcon>