[dotnet watch] Fix device prompt hang for MAUI workload projects

[jonathanpeppers]

Summary

Fixes a bug where dotnet watch's device selection prompt hangs when it appears as the second prompt after a target framework prompt, specifically for MAUI workload projects.

Root Cause

For multi-TFM MAUI projects, the ComputeAvailableDevices MSBuild target is defined in workload .targets files that are only imported when TargetFramework is set (via a conditional <Import>). When dotnet watch loads the project graph with a null TFM to discover available frameworks, the outer multi-TFM project doesn't have TargetFramework set, so the workload import never fires and ComputeAvailableDevices is not visible.

The old code checked rootProject.Targets.ContainsKey(ComputeAvailableDevices) on this outer project, found nothing, and skipped device selection entirely. The child dotnet run process (which runs with a specific TFM) then discovered the target and showed its own device prompt. This created a stdin race between dotnet watch's Console.ReadKey() loop and the child process's Spectre.Console prompt, causing the hang.

Fix

After TFM selection, use projectGraph.TryGetProjectNode(path, targetFramework) to look up the TFM-specific inner project node (which has the conditional imports resolved) and check its targets for ComputeAvailableDevices.

Testing

• Added DotnetRunDevicesWorkload test asset that simulates MAUI workload behavior with a conditionally-imported Devices.targets file
• Added SelectsFrameworkThenDevice integration test (passes with unconditional targets)
• Added SelectsFrameworkThenDevice_WorkloadConditionalTarget integration test (hangs without fix, passes with fix)
• Added SelectsFrameworkThenDevice unit test for the prompt flow

[Copilot]

Pull request overview

Fixes a dotnet watch hang when a device-selection prompt follows a target-framework-selection prompt for MAUI/workload-style projects where ComputeAvailableDevices is only available in TFM-specific inner builds (conditional workload imports).

Changes:

• Updates device-selection gating logic to check the selected TFM’s inner project node for ComputeAvailableDevices.
• Adds a new test asset that simulates workload conditional imports of device targets.
• Expands integration + unit test coverage for “TFM prompt → device prompt” interactive flows.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
test/TestAssets/TestProjects/DotnetRunDevicesWorkload/Program.cs	New test app that prints selected device/RID (via generated DeviceInfo) to validate prompt flow.
test/TestAssets/TestProjects/DotnetRunDevicesWorkload/DotnetRunDevicesWorkload.csproj	New multi-TFM test project; conditionally imports device targets to mimic MAUI workload behavior.
test/TestAssets/TestProjects/DotnetRunDevicesWorkload/Devices.targets	Provides ComputeAvailableDevices/DeployToDevice targets only when imported in inner builds.
test/dotnet-watch.Tests/HotReload/MauiHotReloadTests.cs	Adds integration tests covering sequential TFM + device prompt flow, including workload-conditional target scenario.
test/dotnet-watch.Tests/HotReload/BuildParametersSelectionPromptTests.cs	Adds unit test verifying Spectre prompt flow remains functional across multiple sequential prompts.
src/Dotnet.Watch/Watch/HotReload/HotReloadDotNetWatcher.cs	Switches device-selection check to use the selected TFM’s project graph node so workload targets are visible.