[New Feature]: Support OIDC trusted publishing for verified publishers

Nobody has claimed this yet.

### Description of the new feature/enhancement

Automated WinGet publishers should be able to authenticate with an OpenID Connect (OIDC) identity from their CI workflow instead of storing a long-lived classic GitHub personal access token with the `public_repo` scope.

Today, a publisher workflow must update a fork and open a pull request against `microsoft/winget-pkgs`. The source repository's `GITHUB_TOKEN` is scoped to that repository, while a fine-grained PAT or publisher-owned GitHub App installed only on the fork cannot create the cross-fork pull request. As documented in microsoft/winget-create#595 and microsoft/winget-create#677, that leaves a broad, user-bound classic PAT as the supported automation credential.

Please add an OIDC trusted-publishing path as part of the Verified Developer work in #325096. A verified publisher could register a trusted identity such as:

- OIDC issuer
- immutable repository ID
- allowed workflow reference
- optional branch, tag, or deployment-environment restrictions
- package identifiers the identity may publish

A GitHub Actions workflow would request `id-token: write` and submit the generated manifests together with its short-lived OIDC token. A Microsoft-hosted WinGet submission service would verify the token and registration, then use a Microsoft-owned GitHub App installed on `winget-pkgs` to create the pull request or enqueue the submission. The resulting pull request should record the verified publisher identity and relevant provenance.

This would provide:

- no reusable publishing secret in the publisher repository
- narrow authorization to an exact repository, workflow, and package
- automatic credential rotation through short-lived tokens
- auditable publisher provenance
- no need to grant publishers write access to the community repository

Trusted publishing should not bypass the existing manifest validation, installer scanning, or moderation pipeline by default. It should establish who submitted a manifest and authorize only the registered package identifiers. It could later integrate with the automatic approval flow proposed in #89190.

Microsoft already offers a comparable OIDC trusted-publishing model for NuGet: https://learn.microsoft.com/nuget/nuget-org/trusted-publishing

Related authentication limitations:

- microsoft/winget-create#595
- microsoft/winget-create#677
- vedantmgoyal9/winget-releaser#172
- vedantmgoyal9/winget-releaser#321

### Proposed technical implementation details (optional)

1. Add trusted-publisher registrations to the Verified Developer onboarding process.
2. Add an audience-scoped OIDC exchange/submission endpoint operated by WinGet.
3. Add a `wingetcreate submit --oidc` mode that obtains the CI provider's token and submits the manifest bundle.
4. Validate issuer, audience, repository ID, workflow identity, ref/environment restrictions, and allowed package identifiers.
5. Submit through a Microsoft-owned GitHub App and attach the verified identity and provenance to the pull request/check.
6. Initially support GitHub Actions; design the registration format so other OIDC-capable CI systems can be supported later.

Start by reading the Verified Developer work in #325096 and the related authentication issues linked in the description, then review the proposed `wingetcreate submit --oidc` entry point and trusted-publisher registration flow. Done would require an agreed registration format, OIDC submission and validation path, Microsoft-owned GitHub App integration, and provenance recorded on the resulting pull request or check.

Written by the indexing model from the issue text.