[madhur310]

Summary

• openvsx-publish-release-vsix.yml and vscode-promote-prerelease.yml both ran ovsx publish against a PAT (-p $OVSX_PAT / $IDEE_OVSX_PAT). Both now use ovsx publish --trusted-publishing, which exchanges this job's GitHub Actions OIDC ID token for a short-lived publish token instead — requires id-token: write, which both workflows now grant.
• Open VSX's trusted-publisher config binds one identity per extension to the exact workflow file that requests the OIDC token (its job_workflow_ref). vscode-promote-prerelease.yml's ovsx leg previously ran its own ovsx publish inline, in the same matrix job as vsce — a different file from openvsx-publish-release-vsix.yml, which the stable release path uses. That meant two different job_workflow_ref values for the same extension's Open VSX publishes, which a single trusted-publisher entry can't match.
• Split the ovsx leg out of that matrix job (a uses:-based job can't share a matrix with per-leg different targets) into its own publish-ovsx job that delegates to openvsx-publish-release-vsix.yml via uses:, instead of duplicating the publish logic. Every Open VSX publish for a given extension — stable, stable hotfix, prerelease, prerelease/emergency hotfix — now requests its OIDC token from that one file.
• openvsx-publish-release-vsix.yml gained optional vsix-name-pattern/exclude-web-vsix inputs (default-compatible) so the delegated call can reproduce vscode-promote-prerelease.yml's existing filtering for monorepo/multi-extension callers (e.g. salesforcedx-vscode's salesforcedx-vscode-*.vsix pattern).
• vsce/Marketplace publishing (VSCE_PERSONAL_ACCESS_TOKEN) is untouched.

Validation

• actionlint on both files: zero new findings vs. main (pre-existing shellcheck notices only).
• Traced both existing callers in forcedotcom/salesforcedx-vscode (publishOpenVSX.yml, promote-to-prerelease.yml): neither needs any change, since the new inputs default to current behavior and the renamed/split job (publish → publish-vsce/publish-ovsx) is internal to this reusable workflow.

Test plan

• Merge
• Configure the Open VSX trusted-publisher entry for each affected extension against openvsx-publish-release-vsix.yml
• Dry-run vscode-promote-prerelease.yml from a consumer and confirm publish-ovsx resolves correctly and tag-promoted still gates on both publish-vsce and publish-ovsx
• Next real nightly→prerelease promotion and stable release both confirm ovsx publish --trusted-publishing succeeds without IDEE_OVSX_PAT

@W-24666922@

[madhur310]

Closing in favor of a narrower approach. Turns out Open VSX's trusted-publisher matching checks the OIDC token's workflow_ref claim (the top-level/triggering workflow in the repo that started the run), not job_workflow_ref (which this PR's consolidation targeted) -- confirmed against eclipse-openvsx/openvsx's GitHubTrustedPublishingProviderSupport.matches() and TrustedPublishingService source. Since job_workflow_ref is only ever recorded for audit, not matched, consolidating the reusable workflow in this repo never actually closed the gap: salesforcedx-vscode's stable (publishOpenVSX.yml) and prerelease (promote-to-prerelease.yml) runs are started by two different top-level files regardless of what runs underneath them, and Open VSX only allows one trusted-publisher registration per extension (hard server-side check, not just a UI gap).

The real fix has to make both channels share one top-level workflow file in salesforcedx-vscode itself. A replacement PR will follow carrying forward just the openvsx-publish-release-vsix.yml PAT -> --trusted-publishing migration (still needed, since the new salesforcedx-vscode-side workflow will delegate to it) -- dropping this PR's vscode-promote-prerelease.yml job-split, which is no longer needed.