Keep manifest file executable bit metadata consistent

Description of the new feature/enhancement

Some manifest files in this repository are marked as executable in the Git metadata. This is clearly incorrect – there's no meaningful way of "executing" a manifest file – so for consistency these files should have the executable flag cleared.

There's no practical impact of this flag for this repository; I can't imagine anything that consumes data from the repository will actually care. Certainly Git for Windows won't, and winget itself clearly doesn't. The exception is folk like me, who get upset by unnecessary inconsistencies when they spot them, even if they don't have any practical impact…

For context, Git's storing the executable flag of any given file is a result of Git's Linux history: Linux systems (and I believe most Unix systems) tend to store whether any given file is executable, meaning either it's an appropriately compiled binary or it has a header that indicates the interpreter (Python, Perl, Bash, …) that should be used to run the file. Windows file systems don't work the same way; while NTFS does have the concept of whether a user has permission to execute any given file, in general a Windows user can execute any file they have access to.

Git for Windows handles this sort of thing as expected: it ignores the executable flag on any given file, checks out all files with normal Windows permissions – including the current user having permission to execute all files – and commits all files with the flag cleared unless the user has explicitly requested otherwise using git update-index --chmod.

At least some of the files that have this flag set are ones that I uploaded. I expect they're all due to variations of the error I made: using tools like YamlCreate.ps1 or the Windows Package Manager Manifest Creator – which generate files using Windows-style permissions – then creating pull requests using some version of Git that expects Linux style permissions (Cygwin is the culprit for me, I could believe WSL might cause similar problems with some usage patterns).

Proposed technical implementation details (optional)

Run through the existing manifest files and remove the executable flag. I've already done this, in #89511

Optionally: add something to the existing automation in this repo that will either (a) test and flag when a file unexpectedly has the executable bit set, or (b) automatically create new commits or edit existing commits to clear the flag.

I don't think there's any better way to spot these flags being mis-set; if this were a Git repository on a private server, it might be possible to configure some Git hooks to (say) reject attempts to push commits that have executable files, but (not unreasonably!) that's not function that GitHub exposes.

Review the manifest files and the existing automation in this repository, then inspect pull request #89511, which the issue says already removed the executable flags. Confirm whether any affected files remain and whether the requested validation belongs in current automation; done means the manifest metadata is consistent and any proposed check has a clear repository-wide result.