Doc gap: deprecated spec-gen-sdk label config has no deprecation signal pointing to spec-gen-sdk-runner / centralized sdkLabels

## Summary

There is a documentation/discoverability gap around SDK PR label configuration in `tools/spec-gen-sdk`. The existing label-related config and execution-report fields appear to be deprecated, but the tool does not signal that or point contributors to the current mechanism in `Azure/azure-rest-api-specs`.

## What happened

In PR Azure/azure-sdk-tools#15887, a contributor added a new SDK pull-request label feature for build failures (`buildFailedLabel` / `shouldLabelBuildFailed`) to `spec-gen-sdk`, patterned after the existing breaking-change label configuration:

- `tools/spec-gen-sdk/src/types/SwaggerToSdkConfig.ts` added `buildFailedLabel` under `packageOptions`
- `tools/spec-gen-sdk/src/automation/reportStatus.ts` emitted `buildFailedLabel` / `shouldLabelBuildFailed` into the execution report
- `tools/spec-gen-sdk/src/types/SwaggerToSdkConfigSchema.json` and `tools/spec-gen-sdk/src/types/ExecutionReportSchema.json` added schema fields

During review, @raych1 pointed out that this should be implemented in `spec-gen-sdk-runner` instead of the individual `spec-gen-sdk` tool, because that orchestration layer can be reused as the ecosystem moves from `spec-gen-sdk` toward `azsdk-cli`.

## Why it's confusing (the gap)

The deprecated surface looks like the obvious place to extend because `spec-gen-sdk` still contains:

- `swagger_to_sdk_config.json` / `packageOptions.breakingChangesLabel`
- execution-report fields such as `breakingChangeLabel` and `shouldLabelBreakingChange`
- schemas/types documenting those fields as normal supported contract members

However, the current non-deprecated SDK-labeling architecture appears to live in `Azure/azure-rest-api-specs`:

- label names are centralized in `.github/shared/src/sdk-types.js` in the `sdkLabels` map
- label decisions/signals are produced by `eng/tools/spec-gen-sdk-runner/`, for example `src/command-helpers.ts` (`getBreakingChangeInfo` + `generateArtifact`), which writes `spec-gen-sdk-artifact.json` with a `labelAction`
- labels are applied by `.github/workflows/src/sdk-breaking-change-labels.js`, which reads `spec-gen-sdk-artifact.json` and resolves the actual label name from `sdkLabels` by language
- `spec-gen-sdk-runner` is the generator-agnostic layer and already bridges the future `azsdk-cli` path via `src/azsdk-adapter.ts`

We independently found zero remaining consumers in `azure-rest-api-specs` for the old execution-report fields (`breakingChangeLabel` / `shouldLabelBreakingChange`) or the `swagger_to_sdk_config.json` `breakingChangesLabel` option, which corroborates that the surface is deprecated. But nothing in `spec-gen-sdk` itself made that clear before review.

## Requested documentation/changes

Please consider closing this discoverability gap so future contributors land on the correct extension point first:

1. Add deprecation notices near the label-related `spec-gen-sdk` config/report fields, for example:
- `tools/spec-gen-sdk/src/types/SwaggerToSdkConfig.ts` near `packageOptions.breakingChangesLabel`
- `tools/spec-gen-sdk/src/types/SwaggerToSdkConfigSchema.json`
- `tools/spec-gen-sdk/src/types/ExecutionReportSchema.json` near `breakingChangeLabel` / `shouldLabelBreakingChange`

The notice should state that this label-configuration surface is deprecated and point contributors to centralized `sdkLabels` plus `spec-gen-sdk-runner` for new SDK-labeling behavior.

2. Add a README/docs section, either in `tools/spec-gen-sdk/README.md` and/or a top-level contributor doc, describing the current SDK-labeling architecture:
- where SDK label names live: `Azure/azure-rest-api-specs` `.github/shared/src/sdk-types.js` (`sdkLabels`)
- where the signal is produced: `Azure/azure-rest-api-specs` `eng/tools/spec-gen-sdk-runner/`
- where labels are applied: `Azure/azure-rest-api-specs` `.github/workflows/src/sdk-breaking-change-labels.js`
- how this fits with the migration direction toward `azsdk-cli`

3. Add guidance on the boundaries between:
- `spec-gen-sdk` as the older/phased-out generator-specific tool
- `spec-gen-sdk-runner` as the generator-agnostic orchestration layer
- `azsdk-cli` as the future generation path

This would help contributors know which component to extend for new generation orchestration or labeling behavior.

## References

- PR: https://github.com/Azure/azure-sdk-tools/pull/15887
- Review/thread note from @raych1: https://github.com/Azure/azure-sdk-tools/pull/15887#issuecomment-4625203248
- Relevant `azure-rest-api-specs` paths:
- `.github/shared/src/sdk-types.js` (`sdkLabels`)
- `eng/tools/spec-gen-sdk-runner/`
- `.github/workflows/src/sdk-breaking-change-labels.js`

--generated by Copilot