Holding Alt+Shift+Left/Right to resize panes stalls the UI (4+ panes)

### Windows Terminal version

1.24.11911.0 (stable), also 1.25.1912.0 (Preview), and a local Dev build of current `main`

### Windows build number

10.0.26200.9168

### Other Software

Reproduced with ordinary PowerShell / cmd panes (no special client). Machine: Intel Core Ultra 5 225H, 32 GB RAM.

I already have a fix and will send a PR against this issue.

### Steps to reproduce

1. Open Windows Terminal (stable is enough; Debug Dev builds make it much worse).
2. Split the tab into **4 panes** (`Alt+Shift++` / `Alt+Shift+-`).
3. Focus a pane and **hold** `Alt+Shift+Left` or `Alt+Shift+Right` for a couple of seconds.
4. Repeat while the terminals have a typical amount of scrollback / output.

### Expected Behavior

The splitter should keep moving while the key is held, and the window should stay responsive. Releasing the key should stop the splitter immediately.

### Actual Behavior

Keyboard auto-repeat is ~30 Hz. Each `resizePane` currently calls `_CreateRowColDefinitions()` immediately, which forces a XAML grid relayout **and a reflow of every terminal under that splitter**.

With 4 panes that work costs more than one key-repeat period, so auto-repeat queues more layouts than the UI thread can finish:

- the splitter hitch-steps (stalls a few frames, then jumps)
- occasionally one apply lands after a UI stall and the splitter **jumps half the window**
- in the worst case the window stops pumping messages and has to be killed (ANR)

Stable is already visibly janky. A Debug Dev build makes it easy to freeze the window entirely.

**Before** (stable / unpatched, 4 panes, hold `Alt+Shift+Left/Right`):

**After** (same repro on a local build of the upcoming PR): layout applies are rate-limited to recent UI cost (32–250 ms), at most one in-flight apply, and each apply is capped to a 10% split delta so a stall cannot jump half the screen.

Related but different: #19996 (hang at 1-cell width with a double-width glyph — a reflow crash, not this queueing problem). #19490 sounded similar (freeze while expanding a pane) but closed without a repro.

Reproduce the issue with four panes while holding Alt+Shift+Left/Right and inspect the resizePane path, especially _CreateRowColDefinitions(). Confirm that repeated resizing no longer queues work faster than the UI can process it, the splitter remains responsive, and releasing the key stops movement promptly.

Written by the indexing model from the issue text.