Introduce a Merge Queue to Validate Combined Changes Before Landing

### Feature Description

**What the feature achieves:**
Introduce a merge queue so each PR is tested against the actual state of master it will land on, including any changes queued ahead of it.

For example:
```
M + A -> CI passes -> land A -> M = M + A, let's denote this by M'
M' + B -> CI passes -> land B -> M = M' + B
```
This ensures that the exact combination of changes being introduced into master has passed the required checks.
**Why this feature is needed:**
Two PRs can independently pass CI and have no Git conflicts, but still break master when combined.

For example:
```
M -> stable
M + A -> CI passes
M + B -> CI passes
```
does not guarantee:

`M + A + B -> CI passes`

A merge queue would catch these semantic or integration conflicts before the changes are landed.

### User Experience

**How users will use this feature:**
No changes to User Experience, if CI breaks, users are supposed to rebase their changes and fix the CI and again go through the PR review process again.

### Hudi RFC Requirements

**RFC PR link:** (if applicable)

**Why RFC is/isn't needed:**
- Does this change public interfaces/APIs? No
- Does this change storage format? No
- Justification:

The issue names no files, tests, or implementation entry points. Start by locating the repository's CI and pull-request automation, then trace how changes are validated and landed. Done means queued pull requests are tested against the combined target state before landing, including changes queued ahead of them.

Written by the indexing model from the issue text.