docs: document seed-tag requirement for stable branch cutover

[jwulf]

Summary

The stable/9 release workflow failed with:

Version 2.0.0 doesn't match branch constraint 9.x
Stable branches should only receive patch and minor releases.
Use a BREAKING CHANGE footer on main to bump the major version.

The suggested fix (BREAKING CHANGE footer) was already present — the real cause was different, and the error message misled toward the wrong remediation.

Root cause

python-semantic-release computes the next stable version from the latest non-prerelease tag reachable from HEAD. Prerelease tags (v9.0.0-dev.N) are ignored for this calculation.

On stable/9 the repo still carried legacy v1.0.0…v1.1.3 tags from a previous package incarnation. PSR picked v1.1.3 as the baseline, applied the BREAKING CHANGE bump, and computed 2.0.0. The Validate version matches stable branch gate then (correctly) rejected that version but pointed at the wrong cause.

Verbose PSR log confirmed:

Bumping 1.1.3 with a major bump
Incremented 1.1.3 to 2.0.0

The immediate unblock was to tag v8.9.0 at the v8.9.0-dev.38 commit so PSR had a sensible baseline; the first stable/9 release (v9.0.0) is now published.

Changes

• RELEASE.md § 3 — replace the incorrect "BREAKING CHANGE after v9.0.0-dev.N → 10.0.0" claim with the seed-tag requirement. Add a recovery section for when the validate step fails.
• .github/workflows/publish.yml — rewrite the Validate version matches stable branch error message to:
  • Name the exact non-prerelease tag PSR used as baseline.
  • Give the precise git tag … && git push origin … commands needed to recover.
  • Call out legacy-tag shadowing as a possible cause.
  • Link to the updated RELEASE.md section.

Not addressed in this PR

• Deleting the legacy v1.0.0…v1.1.3 tags. That's destructive and should be a separate, explicitly-acknowledged change.
• The underlying PSR limitation on major bumps on prerelease branches (already documented in MAINTAINER.md § 14).

Verification

• ruff check + pyright — clean (pre-push hook)
• No production code touched; doc + workflow-error-message only.