fix(client): batch scroll wheel input

[andrewting19]

What

Batch mouse wheel scroll steps into a single terminal-input WebSocket message.

Why

On fast scrolls the UI was sending one WS message per step, which creates a lot of churn (serialization + WS traffic + backend fanout) and can contribute to jank/low FPS when many sessions are open.

How

• Accumulate wheel delta, compute whole-step count, and send a single message with the scroll sequence repeated n times.
• Add a unit test covering the batching behavior.

Tests

• bun run lint
• bun run typecheck
• bun run test

[gbasin]

Closing — after reviewing the full input path (wheel event → WS send → server dispatch → tmux write), the batching is unlikely to yield a meaningful performance improvement:

• Browser WebSocket + TCP already coalesces rapid small sends at the transport layer
• In pipe-pane mode each scroll step still triggers a synchronous spawnSync('tmux', ...) regardless of batching, so the server-side cost is identical
• In PTY mode the kernel pipe buffer handles 20 bytes vs 200 bytes identically
• Scroll events only fire for the focused terminal, so the "many sessions" fan-out concern doesn't apply to input

The PR also included an unrelated always-on forceTextPresentation change that would regress non-iOS output.

Appreciate the contribution — if you're seeing actual scroll jank we're happy to dig into root causes together.