Create GitHub releases when tagging

[Rumbles]

Summary

Closes #182.

The tag workflow currently creates and pushes git tags but never creates the corresponding GitHub Releases. As reported in #182, this makes the repo incompatible with Renovate and similar tools that use the GitHub Releases API for action version discovery.

This PR fixes that by having the workflow create a GitHub Release for each new version, with a few additional robustness improvements over #183:

Changes

• Explicit permissions: contents: write at the workflow level — required for GITHUB_TOKEN to create releases (and tags). Without this, the release step fails with 403 in repos whose default token permissions are read-only.
• Replace the git tag + git push --tags step with gh release create --target <sha> — gh release create creates the tag if it doesn't already exist, so a single command handles both.
• Gate on release existence, not tag existence. The loop now skips when gh release view "$tag" succeeds. This makes the workflow:
  • Idempotent. If a previous run pushed the tag but failed to create the release, the next run reconciles the gap. With the tag-existence check, that scenario required manual intervention.
  • Backfill-capable. All pre-existing tags (currently up to v1.0.0) that lack a release will get one on the next run, so Renovate users don't have to wait for the next version bump to start working.
• Walk commits in chronological order (git log --reverse) so each release's auto-generated notes diff against the previous release rather than against an arbitrary newer one.
• Use full SHAs (%H instead of %h) for --target correctness.

Test plan

• Manually trigger the workflow via workflow_dispatch on a branch and verify the existing tags get GitHub Releases created (backfill).
• Push a VERSION bump and verify the new tag and release are both created in a single workflow run.
• Verify Renovate (or gh api repos/databricks/setup-cli/releases) now returns the releases.