fix(mobile): coalesce keyboard viewport settling

[Lint111]

Summary

Coalesce the burst of mobile visualViewport resize events into one final xterm layout and PTY resize after the software-keyboard animation settles.

Root cause

Keyboard open and close used separate fixed 150 ms and 100 ms timers. Mobile browsers report several intermediate viewport heights during the OS animation, so those timers could fit xterm against a transient height and expose another layout/redraw before the final size arrived.

What changed

• reset one 80 ms settle timer on every viewport resize
• preserve the open/close request to return the terminal to the bottom across reschedules
• run the existing fit, padding correction, helper synchronization, and resize transport only after the viewport becomes quiet
• cancel pending settlement during handler cleanup

Commit structure

1. fix(mobile): coalesce keyboard viewport settling

Validation

• focused browser regression: 1 passed
• full test/mobile/keyboard.test.ts: 28 passed, 4 existing unrelated failures
• npm run typecheck
• npm run lint
• npm run check:frontend-syntax
• npm run check:public-assets
• npm run build
• Prettier and git diff --check

The four existing failures are the stale toolbar-transform expectation, outdated accessory action list, and two local-input assertions. The new coalescing regression passes in that same run.

Scope

This PR does not change resize arbitration, mobile terminal controls, input handling, session replay, or authoritative frame capture.

[Ark0N]

Hi Lior, closing this one as part of a cleanup of the seventeen PRs currently open from you. The full explanation is in #173, and I would rather you read that one than this note, because it is the honest version and it is not a dismissal of your work.

The short form: sixteen PRs opened in a single day, roughly 42,000 added lines in total, landing mostly on the same few files (nine touch app.js, eight touch terminal-ui.js), with five already conflicting against master and none carrying CI results. I cannot review that at the standard this codebase needs, and merging it at a lower standard would be worse than not merging it.

Going forward, please keep no more than three open PRs at a time, each one a single behavior change that stands on its own, with a test that fails on master and passes with the fix. #214 and #215, merged today, are good models.

If this particular change fixes something that genuinely annoys you in daily use, it is a good candidate to be the first one you reopen on its own, rebased on current master. I will review it properly.

Thanks for the effort you put in, and sorry to close it this way.