[TypeSpec to SDK] tag release plan with breaking changes introduced in spec review

To deliver dependable client libraries, it is crucial to continuously monitor breaking changes during the SDK release process, particularly those resulting from updates to API specifications, given that API specifications serve as the source-of-truth for SDK generation for all languages. This request suggests tagging each SDK release plan if any of the specified labels are present in the API spec pull request that starts the plan. Refer to [Deep-dive into breaking changes on spec PRs](https://eng.ms/docs/products/azure-developer-experience/design/specs-pr-guides/pr-brch-deep) and [Suppression Case Table](https://eng.ms/docs/products/azure-developer-experience/design/specs-pr-guides/pr-suppressions#suppression-cases-table).

The labels we want to copy into SDK release plans are:

May tag as “**BreakingChange-Approved**”
- BreakingChange-Approved-BugFix, and Versioning-Approved-BugFix
- BreakingChange-Approved-UserImpact

May tag as “**API-Retired-Approved**”

- BreakingChange-Approved-Retired
- Versioning-Approved-Retired

May tag as “**SDK-BreakingChange-Suppression-Approved**”.
Usually, these SDK breaking changes are confirmed to result from approved spec breaking changes.

- BreakingChange-Go-Sdk-Suppression-Approved
- BreakingChange-JavaScript-Sdk-Suppression-Approved
- BreakingChange-Python-Sdk-Suppression-Approved

May tag as “**SDK-BreakingChange-Approved**”

- BreakingChange-Go-Sdk-Approved
- BreakingChange-JavaScript-Sdk-Approved
- BreakingChange-Python-Sdk-Approved

Start with the linked “Deep-dive into breaking changes on spec PRs” and “Suppression Case Table” guidance, then trace how the API spec pull request starts an SDK release plan. Implement the specified mapping from source labels to release-plan tags, and verify that each listed approval or suppression label produces the intended tag.

Written by the indexing model from the issue text.