Next release-candidate release is blocked on tooling#441 (pre-release version continuity across the QualityOnDemand split) #4

Problem description
This repository's first release is seeded from QualityOnDemand's release tag r4.1, where qos-profiles stands at 1.2.0-rc.3. Release Automation's automatic release-candidate/alpha numbering only looks at the current repository's own release history to pick the next number. This repository has none yet, so without a way to carry that version history over, Release Automation would assign rc.1 for the first release candidate here instead of continuing the existing 1.2.0 line at rc.4 — which would break the API's expected version ordering.

Expected action
Wait for camaraproject/tooling#441 (and the accompanying release-plan.yaml schema addition) to be implemented before cutting the first release-candidate release in this repository. Everything else needed to get there is already possible and unaffected by this: seeding the repository's content from QualityOnDemand r4.1, transferring relevant issues, and creating/merging the seed pull request. Only the release cut itself needs to wait, since it depends on the new seeded_from field in release-plan.yaml being available for this repository to declare.

Additional context
This is expected to recur for future repository splits, not just this one — tooling#441 is written as a general mechanism.