WKS-2687 - Compute publish-api release version from git tags

[ehl-jf]

Summary

• publish-api.yml used to compute the next release version via npm version minor against whatever version is committed in api/package.json on main. That's fragile: if a prior run's "merge release branch back to main" step fails or is skipped, main's committed version silently goes stale relative to what's actually been published.
• This happened for real: an unrelated dependency-bump run published npm 0.17.0 successfully, but its merge-back to main never landed. A subsequent run (merging PR WKS-2687 - Add PlatformCrypto to PlatformContext #70, the PlatformCrypto addition) recomputed the same 0.17.0, saw the tag already existed, and silently skipped the entire publish via the existing "already released" guard — so a real, merged feature change was never actually published, with no failure signal anywhere.
• Fix: compute the next version from the latest jfrog-workers/* git tag on the remote (the true source of truth for what's been published) instead of from main's committed package.json, which is now treated as a mutable placeholder that can safely go stale.
• Second commit hardens the new step with set -euo pipefail plus a guard on the one grep that legitimately produces zero matches on a first-ever run (so the "no tags yet" bootstrap path still falls through cleanly instead of the script aborting).

Test plan

• Tag-sort logic validated against the real remote tags (correctly resolves 0.17.0 as latest)
• Confirmed old logic recomputes the same colliding 0.17.0 and would still silently skip; new logic correctly computes 0.18.0
• Verified set -euo pipefail + grep guard: genuine pipeline failures still abort loudly; the legitimate empty/no-tags case still falls through to the package.json fallback
• YAML validated
• After merge, manually trigger via workflow_dispatch to actually publish the pending PlatformCrypto change (merging this workflow-only change won't itself trigger a release, since it doesn't touch api/**)