Packaged WinUI dotnet test activation loses the execution ID

Describe the bug

Native .NET 10 dotnet test can register and AUMID-activate a packaged WinUI test application successfully, but discovery never starts and the run completes with 0 tests because the controller and activated host use different TESTINGPLATFORM_DOTNETTEST_EXECUTIONID values.

DotnetTestConnection creates TESTINGPLATFORM_DOTNETTEST_EXECUTIONID when it is absent and sends that value in the native dotnet-test handshake. PackagedAppTestHostLauncher.GetConnectBackEnvironment explicitly forwards controller/retry/report correlation variables across the AUMID activation boundary, but currently omits this execution ID. An AUMID-activated process does not inherit the controller environment, so the activated host generates a new GUID and the protocol rejects or fails to associate the connection.

Version used

• MSTest.Sdk 4.4.1
• Microsoft.Testing.Extensions.PackagedApp 2.4.1 (stable Windows asset selected with MicrosoftTestingExtensionsPackagedAppVersion=2.4.1)
• .NET 10 SDK selected by global.json
• global.json test runner: Microsoft.Testing.Platform
• Windows x64 packaged WinUI 3 test application
• The same omission is present on current main

Steps To Reproduce

1. Create a WinUI 3 packaged test application that uses MSTest.Sdk and includes a generated AppxManifest.xml for an x64 full-trust application.

2. Select native Microsoft.Testing.Platform dotnet test in global.json.

3. Pin/override Microsoft.Testing.Extensions.PackagedApp to stable version 2.4.1.

4. Clear stale package registrations and test-host processes.

5. Run:

   dotnet test --project <packaged.csproj> -c Release -a x64 --diag <diagnostics-path> -bl:<binlog-path>
   

6. Observe that the Windows PackagedApp asset is resolved, the development package is registered, and the intended x64 executable is activated by its exact AUMID.

7. Compare the controller and activated-host diagnostics/handshake payloads: the controller execution ID differs from the child-generated execution ID.

8. Observe that native dotnet-test discovery never starts and the run reports 0 tests.

Control cases:

• dotnet run succeeds with package identity and AUMID activation.
• An unpackaged WinUI dotnet test succeeds.
• A loose-copy launch is not an acceptable packaged-app validation because it bypasses package identity and AUMID activation.

Expected behavior

The explicit PackagedApp connect-back handoff preserves the controller's TESTINGPLATFORM_DOTNETTEST_EXECUTIONID across AUMID activation. The activated packaged host uses the same execution ID, connects to the native .NET 10 dotnet-test controller, discovers and executes tests, publishes results, exits cleanly, and leaves no stale registration or handoff file.

Actual behavior

Registration and AUMID activation succeed, but the activated host does not receive TESTINGPLATFORM_DOTNETTEST_EXECUTIONID. It generates a different GUID, the controller cannot associate the handshake with the intended execution, and the run finishes with 0 discovered tests.

Additional context

Root-cause hypothesis: add TESTINGPLATFORM_DOTNETTEST_EXECUTIONID to the existing explicit safe connect-back environment allowlist used by PackagedAppTestHostLauncher.GetConnectBackEnvironment, preferably via the shared internal environment-variable constant where project references permit it. Do not broaden the handoff to arbitrary environment propagation.

Security/data-handling invariant: only protocol metadata required for connect-back and correlation should cross the AUMID boundary. Test filters, inline runsettings, credentials, and unrelated or secret environment values must remain excluded. The LocalState handoff must remain one-shot and be deleted after consumption or failed activation cleanup.