Provide mechanism to report SHA256 mismatch

Description

When a package fails to install for any reason - SHA256 mismatch, an uncooperative installer, a download failure, etc. - the client should provide an easy in-CLI mechanism to report the failure so the core team / validation service can track and resolve it.

Behavior

• Provide a way to report a failed install directly from the command line (a report command, or a flag on install).
• Reporting should open (or point to) the appropriate tracking artifact - typically an Issue in winget-pkgs - and return that URL to the user.
• For manifest / catalog-health failures (e.g., SHA256 mismatch), reporting should trigger the validation service to attempt an automatic correction of the manifest.
• Deduplicate: if a report already exists for the same package + failure (e.g., same package and hash), return the existing Issue URL rather than creating a new one. Once the issue has been corrected, it should be closed.

Proposed shape (from #920)

• Command: report [name | moniker]
• Options:
  • -t, --text - text to include in the report
  • -o, --log - include logs / error output from the last install attempt

Notes

• Consolidates #920 (general install-failure reporting) with the original SHA256-mismatch reporting scenario.

Start by reading the proposed command shape and the related #920 discussion, then review how failed installs and package names or monikers are currently handled in the CLI. Check the winget-pkgs issue workflow and validation-service expectations; done means a report can return or create the appropriate tracking URL, include requested text or logs, and avoid duplicate reports.