iPadOS: voice dictation in input bar stops after ~5s (system & third-party keyboards)

## Bug: voice dictation in the input bar is interrupted after a few seconds (iPadOS, both system and third-party keyboards)

### Environment
- **Device:** iPad (iPadOS)
- **Client:** QuickTUI native app
- **Server:** QuickTUI v1 on Windows 11, qscn session backend, connected over Tailscale
- **Reproduced with:** both the built-in system keyboard **and** a third-party keyboard (e.g. 搜狗/Baidu etc. dictation)

### Symptom
While using **voice dictation / speech-to-text** in the terminal **input bar**, the dictation session is **automatically stopped after a few seconds** (roughly 3–5 s), every time, regardless of which input method is used. Text captured up to that point stays, but the microphone/dictation stops and you have to start over.

### What I've checked
- This is **not** an input-method issue — it happens identically with the system keyboard and with third-party keyboards.
- The input bar itself works fine for typed input; only dictation is cut off.
- Not reproducible outside QuickTUI (dictation works fine in other apps on the same iPad).

### Likely cause
Looking at the client bundle, QuickTUI actively manages the mobile keyboard/viewport:
- `mobileInput.blur()` is called during viewport sync (`syncViewportSize` / `syncViewportAndFit`, e.g. after terminal resize / keyboard frame changes).
- There is a `keepSizeOnKeyboard` mechanism that re-lays-out the viewport when the keyboard geometry changes.
- A WebSocket **heartbeat ping runs every 5 s** (`setInterval(..., 5e3)`).

On iOS, **dictation stops immediately if the first responder (the focused text view) loses focus or is re-laid-out / re-created**. A viewport re-layout or focus shift triggered by terminal activity / heartbeat / keyboard-frame changes would cut dictation — matching the "after a few seconds" behaviour and why it's independent of the keyboard app.

### Steps to reproduce
1. Open a terminal session in the QuickTUI app on iPad.
2. Tap the input bar and start voice dictation (system or third-party keyboard).
3. Wait ~3–5 s → dictation stops on its own.

### Expected
Dictation should keep running until the user stops it or sends the message.

### Suggested fix areas
- Avoid calling `blur()` / re-laying-out the input bar while an input is being dictated.
- Defer or skip viewport re-sync while the text view has an active dictation session (`UITextInput`/`UITextInteraction` in-progress).
- Ensure the 5 s heartbeat and terminal output rendering do not trigger a keyboard frame or first-responder change that kills dictation.

Thanks for the great app — happy to provide more detail or test a fix if needed.

Trace the client bundle's mobileInput handling, especially syncViewportSize/syncViewportAndFit and the 5-second WebSocket heartbeat. Reproduce dictation while watching focus, viewport, keyboard-frame, and terminal-rendering events to identify what interrupts the first responder. Done means dictation remains active until the user stops or sends the message, without breaking typed input or keyboard resizing.

Written by the indexing model from the issue text.