Validation: wingetbot hash-mismatch automation picks up Windows OS version instead of app version

Nobody has claimed this yet.

## Summary

The wingetbot hash-mismatch automation is producing manifest updates with incorrect version detection, causing validation failures. When the bot detects a hash mismatch and regenerates the manifest, it sometimes picks up the **Windows OS build version** from the installer binary's metadata instead of the actual application version.

## Example

**PR:** https://github.com/microsoft/winget-pkgs/pull/378524
**Package:** `NHNCorporation.Dooray!Messenger`

The bot created a new manifest version `11.00.26100.1 (WinBuild.160101.0800)` — this is clearly a Windows build string, not the Dooray Messenger version. The `AppsAndFeaturesEntries.DisplayVersion` in the same manifest correctly shows `2.2.2`, confirming the actual app version hasn't changed.

Validation fails with:
> Manifest Error: DisplayVersion declared in the manifest has overlap with existing DisplayVersion range in index. Existing DisplayVersion range in index: [ [2.2.2, 2.2.2]]

## Root Cause

The installer EXE (`DoorayMessengerSetup-x64.exe`) likely has Windows OS version metadata embedded in its binary properties (e.g., from the Electron/Chromium runtime or the IExpress wrapper), and the bot is reading that instead of the actual product version when generating the `PackageVersion` field.

## Impact

- Creates PRs that will always fail validation (version overlap).
- Pollutes the PR queue with unfixable bot PRs.
- This pattern likely affects other packages where the installer binary embeds OS/runtime version strings in its metadata.

## Suggested Fix

The version detection logic in the hash-mismatch automation should prefer `AppsAndFeaturesEntries.DisplayVersion` or other product-specific version fields over raw binary file version metadata, especially when the detected version matches known Windows build version patterns (e.g., `XX.00.XXXXX.X (WinBuild.XXXXXX.XXXX)`).

No source file, test, or entry point is named. Start by tracing the hash-mismatch automation from PR 378524 and compare how it derives PackageVersion with AppsAndFeaturesEntries.DisplayVersion; done means the generated manifest uses the application version and passes validation without a Windows build string.

Written by the indexing model from the issue text.