feat(publish): add Open VSX pre-release publishing step

[edelauna]

Problem (one or two sentences)
Open VSX (used by VSCodium, Cursor, Windsurf, etc.) sees roughly ¾ the download volume of the VS Code Marketplace, but Zoo Code only publishes pre-releases to the Marketplace — Open VSX users have no way to opt into pre-release builds.

Context (who is affected and when)
Affects all Open VSX users whenever a new pre-release is cut. They're stuck waiting for stable releases while Marketplace users get early access, widening the gap on the platform that already lags in downloads.

Desired behavior (conceptual, not technical)
Pre-releases should land on Open VSX at the same time as the Marketplace, under the same extension ID, so Open VSX users can choose "Install Pre-Release Version" just like Marketplace users can today.

Constraints / preferences (optional)

• Same extension ID/namespace; pre-releases coexist with stable (no second extension).
• Open VSX does NOT support semver pre-release tags like -beta.1 — pre-releases must use a distinct x.y.z. This aligns with Zoo Code's odd/even-minor scheme: odd minors (e.g. 3.55.x) are pre-release lines, even minors are stable.
• Reuse the existing publish workflow token (OVSX_PUBLISH_TOKEN) rather than a separate publish path.

Acceptance criteria (optional)
Given a new pre-release is published
When the publish workflow runs with the pre-release flag
Then the build is published to Open VSX with ovsx publish --pre-release using the same VSIX as the Marketplace publish
And the extension shows a "Pre-Release" badge on open-vsx.org
And users can select "Install Pre-Release Version" in VSCodium/Cursor
But the stable release is unaffected (no version clobbering)

Proposed approach (optional)
Add an ovsx publish --pre-release step to the existing publish workflow, mirroring the pattern used by spring-projects/spring-tools (.github/workflows/publish-vscode-extension-pre-release.yml): build one VSIX, then vsce publish --pre-release to Marketplace and ovsx publish --pre-release to Open VSX. ovsx supports --pre-release natively — no second extension needed.

Trade-offs / risks (optional)

• Version-collision risk if a pre-release x.y.z is later reused for stable — mitigated by the odd/even-minor convention keeping pre-release and stable on distinct versions.
• Scope creep into the existing publish workflow (feat: add build provenance attestation to publish workflows #781 touches the same files; should be coordinated).
• Requires the OVSX_PUBLISH_TOKEN secret to be present (already needed for stable Open VSX publishes).

Reference

• Spring Tools pre-release workflow: https://github.com/spring-projects/spring-tools/blob/main/.github/workflows/publish-vscode-extension-pre-release.yml
• openvsx pre-release support: publishing pre-release, target-specific .vsix to open-vsx.org eclipse-openvsx/openvsx#503
• Open VSX publishing wiki: https://github.com/eclipse-openvsx/openvsx/wiki/Publishing-Extensions

[edelauna]

Investigation summary

Verified against the Open VSX registry source (eclipse-openvsx/openvsx) and live testing against production:

Mechanism (ground truth): ExtensionVersionJooqRepository.findLatestQuery (server/src/main/java/org/eclipse/openvsx/repositories/ExtensionVersionJooqRepository.java:1287-1315) resolves both the latest and pre-release version aliases:

• pre-release alias: filters to PRE_RELEASE = true, then orders by semver desc, limit 1.
• latest alias: no pre-release filter at all — orders by semver desc across all versions, with SEMVER_IS_PRE_RELEASE ASC only as a tie-breaker for identical major.minor.patch.

Net effect: latest always resolves to the highest-numbered published version, whether it's flagged pre-release or not. A pre-release can transiently become latest if it outranks the current stable — this is not a bug, it's the intended "newest wins" model, and it mirrors how VS Code Marketplace pre-release users already track the newest published build. It self-corrects the next time a higher-numbered stable is published.

Confirmed live by publishing a real pre-release test build and a follow-up stable build to ZooCodeOrganization.zoo-code:

• pre-release alias correctly isolated the pre-release version.
• latest briefly tracked the pre-release (highest semver at the time), then correctly moved to the next stable once one was published above it — exactly matching the source logic.

Decision: proceed with adding ovsx publish --pre-release to nightly-publish.yml, accepting that nightly builds may transiently surface as latest on Open VSX until the next stable release, the same trade-off already accepted for VS Code Marketplace pre-release publishing.

Housekeeping: the investigation left three throwaway versions on the real ZooCodeOrganization.zoo-code Open VSX listing (3.65.900001, .900002, .900003) since Open VSX has no unpublish/delete support (eclipse-openvsx/openvsx#58). 3.65.900003 is a faithful rebuild of v3.64.0 and is currently latest; the other two are harmless historical clutter that could be marked deprecated via the Open VSX web UI at some point.