Allow backport workflow callers to provide multiple target branches

## Summary

The reusable backport workflow currently extracts one target branch from a `/backport [to] ` comment and runs one backport operation. Add generic support for a caller to provide multiple already-resolved target branches while preserving existing single-target behavior.

The first consumer and its product-specific target-resolution policy are tracked in dotnet/sdk#55929.

## Proposed reusable-workflow contract

Add an optional `target_branches` input to `.github/workflows/backport-base.yml`. The value would be a JSON array of branch names.

- When omitted, preserve the current comment parsing and single-target behavior.
- When provided, validate and deduplicate the array, enforce a reasonable target-count limit, and run the existing backport worker once per target with a matrix.
- Use `fail-fast: false` so a conflict or failure for one branch does not cancel independent backports.
- Keep existing branch-existence checks, authorization, merged-source validation, cherry-picking, conflict reporting, PR creation, labels, and comment relocking in Arcade.
- Ensure cleanup runs once per workflow invocation rather than once per matrix entry.

Target resolution is intentionally outside Arcade. Callers decide how aliases map to branches and pass only concrete branch names. For the SDK consumer, `/backport to ` will fast-exit to a one-element list, while `/backport ` and `/backport all` use SDK-owned release and feature-band policy.

## Compatibility and safety

- Existing callers that do not pass `target_branches` continue to use the current `/backport [to] ` parser.
- Validate that the input is a JSON array containing only permitted branch-name characters.
- Deduplicate before creating the matrix and reject empty or oversized arrays with a clear PR comment.
- Keep temporary branch names target-specific so concurrent matrix entries remain idempotent.

## Feedback requested

- Is a caller-resolved JSON target list the right extension point for `backport-base.yml`?
- Should status reporting remain per target, add an aggregate comment, or provide both?
- Are there matrix concurrency or idempotency concerns beyond the existing target-specific temporary branches?

## Related work

- SDK resolver and branch policy: dotnet/sdk#55929
- Current reusable workflow: https://github.com/dotnet/arcade/blob/main/.github/workflows/backport-base.yml
- Current SDK caller: https://github.com/dotnet/sdk/blob/main/.github/workflows/backport.yml

Start with .github/workflows/backport-base.yml and trace its current comment parsing, backport worker, branch checks, cleanup, and reporting. Review the SDK caller and dotnet/sdk#55929 only for the caller boundary and resolved target list. Done means the optional JSON array supports validation, deduplication, bounded matrix execution with fail-fast disabled, while omitted input preserves existing behavior and cleanup runs once.

Written by the indexing model from the issue text.