Add interactive selection for ambiguous package matches

[AmirMS (AmelBawa-msft)]

📖 Description

Let users resolve ambiguous matches without restarting single-package install, show, and download commands. Opt in with experimentalFeatures.interactivePackageSelection.

• Reuse the existing ambiguity tables with automatic numbering and one row per candidate.
• Apply source priority before prompting and continue with the selected package and original command options.
• Support invalid-input recovery and cancellation with 0 or Ctrl+C.
• Preserve ambiguity errors for noninteractive, redirected, and truncated-result scenarios.

Includes localized strings, regression coverage, release notes, and a UX specification. Narrow terminals use existing table truncation.

🎞️ Demo

🔗 References

• Builds on Validate REST search results against filters and selectors #6514.
• Related issue: Deduplicating results from multiple sources #5345.

🔍 Validation

• Built and deployed x64 Debug wingetdev from d729b8ba on the host. Focused native tests passed: 3,471 assertions across 92 test cases.
• All 34 terminal scenarios passed, covering default-off and opt-in behavior, selection, version lists, invalid/empty/long input, integer boundaries, EOF, cancellation, noninteractive fallback, --silent prompting, and 24-column tables.
• Three native-console GUI scenarios passed at 100 and 45 columns, including --no-vt. UI Automation exposed the table, prompt, retry feedback, and full selected ID.
• All 150 repeated Ctrl+C cases across show, install, and download returned E_ABORT. The slowest cancellation was about 0.118 seconds.
• Install/download scenarios cancelled before acting on a package. Production WinGet was unchanged, development settings were restored, and all test processes and windows were closed.

Screen-reader speech was not tested.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Added or updated tests (or noted why not applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

🤖 AI Assistance

• AI assistance was used and has been disclosed in this PR
• No AI assistance was used

GitHub Copilot assisted with implementation, tests, documentation, code review, and local validation.

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[JohnMcPMS]

It feels like the code should be structured as such:

• WorkflowBase :: Does the top-level decision on flow support for selection, generates table and decides on strings.
• PromptFlow :: Takes in table+strings and determines if prompting is allowed/possible. This is a generic selection flow task. Handles output of the values, input validation and repitition.
• Reporter :: Handles improved input with support for cancellation. Performs no output.

Yes, this also means refactoring the table output into non-templated functions. That is probably for the best anyway.

[ranm-msft]

I checked this against the invariant that matters most for a new prompt: nothing that is not a real interactive console session should ever start waiting on input. That holds here. The disable-interactivity switch, the settings-level disable, hidden and non-output channels, and a redirected stdin or stdout all fall back to the existing multiple-applications-found error rather than prompting, and the unambiguous single-match path is untouched. Strings are in the resource file with the placeholders locked, and there are tests for both the non-interactive fallback and user cancellation.

Two things I would want settled before this goes in.

The first is evidence rather than design: the build and test job is skipped at the current head, so nothing has actually run the new tests. I would like a green run before merge, since the whole value of this change is that the prompt appears exactly when it should and never otherwise.

The second is the product question already on the thread. Deliberately letting the silent switch through to this prompt is defensible - silent describes installer behavior, not CLI interactivity - but it is the kind of decision that surprises someone scripting against the CLI. Routing a new interactive surface through the experimental feature process first would let us change our minds cheaply. I do not feel strongly about which way that lands, only that it should be an explicit call.

[JohnMcPMS]

Do these need to be public? I didn't see any product use of them outside of the implementation .cpp.

[JohnMcPMS]

With the change to use those existing tables, the operation type should no longer be a blocker. Unless the blocker was more about deciding which paths should enable selection.

[JohnMcPMS]

Should this just be output regardless of selection support?