feat: automate release process

[NicoleMGomes]

Disclaimer: Do not include SAP-internal or customer-specific information in this PR (e.g. internal system URLs, customer names, tenant IDs, or confidential configurations). This is a public repository.

Description

Replaces the manual GitHub-Release-driven publish flow with a fully automated issue-driven pipeline. A new /release-prep skill diffs the branch against the latest tag, classifies commits by Conventional Commit type, proposes a SemVer version bump, generates structured release notes, and creates a GitHub Issue with release + status: pending tests labels. An external automation test repo monitors those issues, runs tests, and updates the status label. When status: tests passed is applied, the refactored release.yml workflow bumps pyproject.toml, commits, tags, builds, creates the GitHub Release, publishes to PyPI via OIDC, and closes the issue. A /prep-pr skill fills in the PR template from the branch diff. check-version-bump.yaml now rejects manual version changes in PRs — the release workflow owns all version bumps. docs/RELEASE.md is rewritten to document the new process end-to-end.

Related Issue

Closes #<issue_number>

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Dependency update

How to Test

1. Run /release-prep on any branch with commits ahead of the latest tag — confirm a release issue is created with labels release + status: pending tests and structured ### Version / ### Branch / ### Release Notes sections in the body.
2. Manually add label status: tests passed to a release issue — confirm the Release workflow triggers, parses the issue body correctly, and progresses through label states (releasing → released).
3. Open any feature branch and run /prep-pr — confirm it proposes a filled-in PR body derived from the diff and offers to create or update the PR.
4. Open a PR that modifies the version = line in pyproject.toml — confirm check-version-bump.yaml fails with the message directing to /release-prep.
5. Review docs/RELEASE.md — confirm the pipeline diagram, step numbering, and failure-handling table match the actual workflow behaviour.

Checklist

• I have read the Contributing Guidelines
• I have verified that my changes solve the issue
• I have added/updated automated tests to cover my changes
• All tests pass locally
• I have verified that my code follows the Code Guidelines
• I have updated documentation (if applicable)
• I have added type hints for all public APIs
• My code does not contain sensitive information (credentials, tokens, etc.)
• I have followed Conventional Commits for commit messages

Additional Notes

validate_prerelease.py (.github/scripts/) is no longer called by the release workflow — pre-release status is now derived inline from the version string. It can be removed in a follow-up. check_version_bump.py is still used by release.yml to validate the issue version is greater than the current pyproject.toml version before bumping.