[feature](ci) Add batch cherry-pick admission (Mergify-like batch mode)

[morningman]

Stack multiple approved PRs targeting a release branch onto one integration branch, run the TeamCity pipeline ONCE, and on green admit + merge the whole batch. Reduces per-PR CI resource usage for bulk master -> branch-4.0/4.1 cherry-picks.

Operators drive it from a per-branch tracking Issue (label batch-queue/) via comments: run batch [#a #b] / rerun batch / cancel batch. A cron poller detects completion, broadcasts admission commit-statuses onto each member PR's head SHA (reusing skip_build's mechanism) and merges members individually so each keeps its own Merged provenance. Single-batch-in-flight per branch, with live-state reconciliation at merge time (skip already-merged/changed/conflicting members). No auto-bisection: failures are handled by the operator.

Reuses teamcity-utils.sh (trigger_or_skip_build / context maps) so all TeamCity URLs, credentials and pipeline mappings stay in one place.

Files:

• .github/workflows/batch-cherry-pick.yml entry (issue_comment + schedule)
• tools/batch-cherry-pick.py orchestrator
• regression-test/pipeline/common/batch-utils.sh thin reuse of teamcity-utils.sh
• tools/batch-cherry-pick.README.md Chinese user + maintainer guide

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?