Validate version against VERSION.md and notify automation repo

[tomleb]

Summary

Replaces the existing tag-push-triggered release workflow with a validated workflow_dispatch flow. The new workflow is the only path that should produce a tag — engineers no longer run git tag locally.

The motivation: today it's easy to tag the wrong version on the wrong branch (e.g. v0.9.x from release/v0.7), and there's no signal to downstream repos that a release happened. The new workflow validates everything before tagging and notifies the central rancher/frameworks-automation repo so the rancher bump PR can open within ~30s.

What it does

Trigger from Actions → Release → Run workflow. Pick the branch (e.g. main or release/v0.7) and enter the version (e.g. v0.9.6). The workflow then:

1. Validates the version:
   • Format v<major>.<minor>.<patch>[-prerelease].
   • The minor matches what VERSION.md says this branch is allowed to release (e.g. release/v0.7 → v0.7.x).
   • Next-sequential against the latest existing tag on that minor line (no skipping v0.7.5 → v0.7.7).
   • Tag doesn't already exist.
   • The required CI workflows (CI, Integration tests) are green on the head SHA.
2. Creates the annotated tag on the head SHA and pushes it.
3. Creates the GitHub Release with auto-generated notes (same as the previous workflow).
4. Notifies the rancher/frameworks-automation repo via repository_dispatch so the reconciler opens the rancher bump PR.

permissions: {} is set at the workflow level so each job runs with only the perms it needs (validate: read-only; release: contents:write).

Setup checklist (before first use)

• Add repo secret AUTOMATION_DISPATCH_TOKEN: a fine-scoped PAT (or GitHub App installation token) with permission to fire repository_dispatch on rancher/frameworks-automation. GITHUB_TOKEN can't dispatch cross-repo. Without this, the notify step fails but the tag/release are still created — the reconciler will pick the tag up on its next 15-min cron.
• Confirm rancher/frameworks-automation exists (this lands in a separate PR). If it doesn't yet, the notify step will fail; same fallback as above.
• (Optional, recommended later) Add a tag protection rule for pattern v* allowing only the App/bot identity to push tags. This makes the new workflow the only way to produce a release tag. Skipping this for now keeps the migration low-risk; engineers can still git push origin vX.Y.Z from a laptop, just shouldn't.

How to release after this lands

Old way (no longer used): git tag vX.Y.Z && git push origin vX.Y.Z.

New way:

1. Go to Actions → Release → Run workflow.
2. Pick the branch you want to release from.
3. Enter the version.
4. Hit Run workflow.

If validation fails, the workflow exits non-zero with a clear ::error:: message and no tag is created. Fix the issue (wrong branch, CI not green, etc.) and re-run.

Known issue / follow-up needed

ci.yaml's push trigger lists master, which appears stale (the default branch is main). Merge commits on main therefore have no CI workflow run, and the new release workflow's "CI green on this SHA" check will fail when releasing from main. Two ways to address:

• Recommended: separate one-line PR adding main to ci.yaml's push.branches. Same fix probably wanted for integration-tests.yaml.
• Workaround: manually re-run CI on main via Actions → CI → Run workflow before triggering Release.

This is independent of this PR but worth doing before relying on releases from main.

Test plan

• On a sandbox branch, run Release with a deliberately-wrong version (e.g. v0.9.5 from release/v0.7) — expect failure at "Validate version matches branch's allowed minor". No tag should appear.
• Run with a non-sequential version (e.g. v0.9.999) — expect failure at "Validate version is next-sequential".
• Run with the correct next-sequential version — expect tag + GH release created, and the dispatch step succeeds (or fails cleanly if the automation repo / secret aren't set up yet).
• Confirm the new tag triggers no other workflow (the old push: tags: v* trigger is gone).