Define source priority behavior for package resolution

[denelon]

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

WinGet supports source priority, but the feature remains experimental and its role in package resolution needs to be explicitly defined.

Source priority should provide simple and predictable behavior when multiple configured sources contain eligible candidates. After user-supplied filters are enforced, priority should act as a hard boundary rather than as one signal in a cross-source scoring mechanism.

This work is a sub-issue of #6435.

Proposed technical implementation details

Define and document:

• how user-supplied --source, --id, --name, --moniker, --exact, and version filters determine candidate eligibility before priority is applied
• how the highest-priority source or sources containing eligible results are selected
• that lower-priority sources do not participate once eligible results exist at a higher priority
• how sources configured with the same priority are handled
• that cross-source package correlation is attempted only when every source at the highest applicable priority has exactly one eligible result
• that multiple results within an individual source remain ambiguous and are not resolved through cross-source correlation
• how source priority behaves across install, show, upgrade, and uninstall
• how installed-package source information constrains the applicable sources for upgrade and uninstall
• how interactive, non-interactive, COM API, and PowerShell callers observe unresolved ambiguity
• what diagnostic output explains that source priority determined the selected package
• whether the current implementation is ready to graduate from experimental status

An explicit --source argument should constrain the applicable sources before priority is evaluated.

Installed-package source selection is tracked by #4347.

The original configurable multi-source behavior request is tracked historically at #1488.