Winget should sanitize product version metadata in registry

Description of the new feature / enhancement

Currently we still have enough installers that fail to set their metadata properly within the registry. This causes winget to incorrectly detect the version number and suggest updating the application erroneously.
Winget should at least sanitize the most common (and easily detectable) mismatches when installing and updating a package. We cannot fix everything, but we can at least fix the generic/common ones to improve the user experience.

Proposed technical implementation details

Error cases:

• the installer wrote "" (nothing), "0.0.0", "1.0.0" or "1.0" into the registry. => The developer didn't provide any version information and the installer wrote a default value => winget should write the expected version into the registry to fix this. Write debug/info message into the log, but don't show any warning or error message.
• The Installer wrote a truncated version into the registry. e.g. "86" or "86.3" instead of "86.3.48958" or "86.3-rc1" => Most likely the installer or build script didn't preserve/support the format or length of the version number. => winget should write the expected version into the registry to fix this. Write debug/info message into the log, but don't show any warning or error message.
• The version number in the registry is prefixed with "v", but otherwise matches what we expected => winget should sanitize the version number by removing the "v" prefix and update it within the registry. Write debug/info message into the log, but don't show any warning or error message.
• All other cases will throw a warning or error (see below).

The last one can be further split into:

• The version number read from the registry is lower than what we expected => Fail the install/update. The most likely case is the installer NOOPed instead of actually doing the install/update. So we should fail instead of returning successfully.
• The version number read from the registry is higher than what we expected AND we were told to install a specific version (I.E. not latest) => The installer either silently auto updated before returning, or NOOPed because a higher version was already installed. We should throw an error.
• The version number read from the registry is higher than what we expected AND we were told to install latest => Throw a warning, most likely the installer auto updated before returning and our metadata file doesn't yet contain the latest version number.
• The version number read from the registry is just different and we cannot tell anything else (I.E. none of the above cases but also not what we expected) => Throw a version mismatch error and fail the install. Together with the above cases we can expect this to only have a minimal impact in cases where the install wasn't silently failing. (I don't know of any software installer, including enterprise, that writes e.g. "2.0" into this field while installing "3.0", if they write incorrect information it is almost always one of the initial two cases).

The issue names no files, tests, or entry points, so begin by locating the install/update path that reads product-version metadata from the Windows registry. Use the listed cases as the behavioral requirements: sanitize recognized defaults, truncation, and v-prefixed values, and fail or warn for the remaining mismatches. Done means these outcomes are covered by tests and the appropriate log messages are produced.