Prepare and queue release pipelines after auto-release SDK PR merges

## Problem

For newly onboarded services, the package folder and pipeline descriptor (for example, `ci.yml`) are created by the SDK pull request. Today, the corresponding Azure DevOps pipelines, including the release pipeline, are created by the nightly `prepare-pipelines` run.

As a result, when an auto-release SDK pull request is merged into the main branch, the release pipeline may not exist yet and cannot be triggered.

Adding an `/azp run prepare-pipelines` comment before merging is not an ideal workaround because it requires manual intervention and performs privileged Azure DevOps mutations based on unmerged content.

## Proposed solution

Monitor merge events to the default branch for auto-release SDK pull requests. When a pipeline descriptor such as `ci.yml` is added or renamed, run the existing `prepare-pipelines` flow immediately against the merged commit.

The flow should:

- Create any missing Azure DevOps pipeline definitions.
- Grant the new definitions permission to use the configured service connections.
- Queue the newly created release pipeline using the merge commit.

Keep the existing nightly batch as a reconciliation mechanism to recover missed events and correct pipeline-definition drift across all SDK repositories.

## Acceptance criteria

- Merging an auto-release SDK pull request that adds or renames a pipeline descriptor triggers `prepare-pipelines` from the repository's default branch.
- Pipeline preparation uses the merged content rather than pull request content.
- Missing pipeline definitions are created and granted access to their configured service connections.
- A newly created release pipeline is queued using the merge commit.
- No manual `/azp run prepare-pipelines` comment is required.
- The nightly `prepare-pipelines` run remains in place for reconciliation and drift correction.