Different UX modes for WinGet

Description of the new feature / enhancement

Sometimes I want winget to behave as simply an "engine" for managing packages. In that case, I want commands to either succeed or fail with meaningful output because no user is at the keyboard to respond to prompts for input.

Other times, I want winget to behave more interactively, so I can have a better UX. For example, when there are multiple packages found matching a command, I don't want to have to type the entire command again, I just want an interactive prompt to save the keyboard strokes.

Related to:

• https://github.com/microsoft/winget-cli/issues/1830

Proposed technical implementation details

I want a setting to define the default behavior.

I want a set of arguments to override the default behavior.

Note, if this is implemented in a 1.x version of WinGet, the default behavior would be in the "engine" mode above to not break existing automation.

Otherwise, this would be considered a breaking change in behavior and would be part of:

• https://github.com/microsoft/winget-cli/issues/2128

Start by reviewing related issues #1830 and #2128 to understand the existing UX and compatibility constraints. Then trace the command-line behavior and configuration entry points for prompts and automation. Done means a documented default mode and override arguments support both non-interactive engine behavior and interactive UX without breaking existing automation.