Feature: Packaging check should detect winget publishing workflows

[mangokingTW]

Is your feature request related to a problem? Please describe.

The Packaging check does not recognize any winget (Windows Package Manager) publishing patterns. IsPackagingWorkflow in checks/fileparser/github_workflow.go has matchers for npm, PyPI, RubyGems, NuGet, cargo, Docker, ko, Maven/Gradle, sbt, Elixir and semantic-release, but none for winget.

As a result, a project that automates publishing to winget — via the winget-releaser action or Microsoft's official wingetcreate CLI — scores Packaging as N/A ("packaging workflow not detected"), even though it does publish packages through an automated workflow.

Describe the solution you'd like

Add winget matchers to IsPackagingWorkflow:

• vedantmgoyal9/winget-releaser (the de-facto community action)
• vedantmgoyal2009/winget-releaser — the same action under its previous owner name; the account was renamed and GitHub redirects it, so unmodified workflows still reference the old path
• a Run matcher for wingetcreate ... submit, which matches Microsoft's official CLI by command name and is therefore owner-agnostic

Describe alternatives you've considered

Matching only wingetcreate would avoid hardcoding a personally-owned action, but would miss the most common real-world publishing path. Supporting a pattern instead of an exact owner would require JobMatcherStep.Uses to accept a regex — stepsMatch currently does exact prefix matching — which touches code shared by all checks and seems better suited to its own change. The configurable allowlist discussed in #1642 would be the general fix.

Additional context

Related to but independent of #5100 / #5101, which propose a --winget input flag so Scorecard can resolve a winget package identifier to its source repo. That is the input side; this issue is the detection side (noticing that a scanned repo publishes to winget). Neither depends on the other.

This is the same category as #5145 (cargo-dist), #5131 (step-security/goreleaser) and #5096 (changesets).

Side effect on Token-Permissions worth deciding on

Anyone implementing this should know IsPackagingWorkflow has two call sites, not one. Besides the Packaging check (checks/raw/github/packaging.go), it is also called by requiresPackagesPermissions (checks/raw/permissions.go:422), whose result feeds createIgnoredPermissions (:341):

if requiresPackagesPermissions(workflow, fp, pdata) {
    ignoredPermissions[permissionPackages] = true
}

So adding these matchers also causes Token-Permissions to stop checking the packages permission in winget publishing workflows. Winget publishing does not actually need packages: write: winget-releaser requires a classic PAT with public_repo scope to open a PR against microsoft/winget-pkgs, and wingetcreate submit works the same way — neither publishes to GitHub Packages.

In practice the exemption only bites when a workflow actually declares a packages permission, which a typical winget workflow does not, so the effect is narrow. It is also pre-existing and broad rather than specific to winget: gem push (RubyGems.org), cargo publish (crates.io), pypa/gh-action-pypi-publish (PyPI), sbt ci-release (Maven Central), hex.publish (hex.pm) and setup-node + registry.npmjs.org don't require packages: write either.

For context, #1642 is where this coupling originated: the matcher list was justified there as "actions we know of" (classification rather than trust), even though the bug being fixed was a Token-Permissions false positive. Narrowing it now would change Token-Permissions results for many existing repos, so it likely deserves its own issue rather than riding along with a new matcher.