spec-gen-sdk: breaking-change label config key mismatch and schema gaps

## Summary While reviewing Azure/azure-sdk-tools#15887, the automated reviewer surfaced several pre-existing inconsistencies in the **breaking-change label** plumbing of `spec-gen-sdk` (unrelated to that PR, which adds a separate, internally-consistent `buildFailedLabel` field). Filing to track. ## Issues 1. **Singular vs plural config key mismatch.** `reportStatus.ts` sources the report's `breakingChangeLabel` only from `packageOptions.breakingChangesLabel` (plural): https://github.com/Azure/azure-sdk-tools/blob/main/tools/spec-gen-sdk/src/automation/reportStatus.ts But both `SwaggerToSdkConfig.ts` and `SwaggerToSdkConfigSchema.json` also expose `breakingChangeLabel` (singular). A config using the singular key would silently emit `breakingChangeLabel: undefined` in the execution report, preventing downstream labeling. 2. **Schema/type out of sync.** `SwaggerToSdkConfig.ts` and the tests use `packageOptions.breakingChangesLabel` (plural), but `SwaggerToSdkConfigSchema.json` only documents `breakingChangeLabel` (singular). 3. **Incomplete execution-report schema.** `generateReport` emits `shouldLabelBreakingChange`, but `ExecutionReportSchema.json` does not define it under the package result (it only defines `breakingChangeLabel`), making the report contract incomplete. ## Suggested fix - Pick one canonical key (prefer `breakingChangesLabel` since that's what is actually read) and support the other as a back-compat alias (prefer one, fall back to the other) before writing the report. - Keep `SwaggerToSdkConfigSchema.json` and `ExecutionReportSchema.json` in sync with the emitted payload (add `shouldLabelBreakingChange`; document both label keys). ## Context Surfaced by review comments on Azure/azure-sdk-tools#15887.