fix(terminal): let the active viewport reclaim PTY sizing

[Lint111]

Summary

Make shared terminal sizing follow the viewport that is actively being used, without letting background restores or reconnects steal the PTY size.

This fixes the mobile-to-desktop recovery failure where the desktop canvas could remain constrained to a prior phone or keyboard layout until the user manually forced a redraw.

Root cause

A Codeman session has one PTY size even when several browser viewports are connected. The previous arbitration treated a desktop WebSocket connection as active simply because it existed, while the browser could also send automatic resizes during restore and tab loading. That made presence, layout announcement, and real user activity indistinguishable.

The browser also repeated fitAddon.fit() during the same keyboard or tab transition, exposing intermediate xterm layouts and adding avoidable visual stutter.

What changed

• Add an explicit takeControl resize option to the session API and WebSocket protocol.
• Keep desktop connection presence separate from recent desktop activity.
• Remember each WebSocket connection's announced viewport and dimensions, then reassert that connection's size before accepted input.
• Let explicit mobile interaction override a fresh desktop claim, and let explicit desktop interaction reclaim the PTY afterward.
• Keep automatic startup, reconnect, solo-window, and session restoration resizes passive.
• Reclaim desktop sizing on terminal/tab interaction and browser focus or visibility recovery.
• Clear stale mobile keyboard layout state before a desktop tab measurement.
• Route keyboard open/close sizing through the same resize API.
• Avoid duplicate xterm fits when the caller already established the current dimensions.

Commit structure

1. feat(terminal): add explicit viewport sizing ownership
   Adds the server arbitration contract, HTTP/WS protocol support, per-socket dimension reassertion, and focused route/unit coverage.
2. fix(terminal): let active viewport reclaim PTY sizing
   Adds browser ownership signals, keyboard-aware layout recovery, reduced redundant fitting, and isolated Playwright coverage.

Validation

• npx vitest run --config config/vitest.config.ts test/session-resize-arbitration.test.ts test/routes/session-routes.test.ts test/routes/ws-routes.test.ts - 126 passed
• npx vitest run --config config/vitest.config.ts test/terminal-touch-tap.test.ts - 20 passed
• Focused test/mobile/keyboard.test.ts viewport-control case - 1 passed
• npx vitest run --config config/vitest.config.ts test/terminal-viewport-ownership.test.ts - 3 passed
• npm run check:frontend-syntax
• npm run check:public-assets
• npm run typecheck
• npm run lint
• npm run build
• Targeted Prettier checks and git diff --check

The complete mobile keyboard file is not claimed green: it currently has four unrelated baseline failures covering the existing accessory list, toolbar transform, CJK/local echo, and SGR tap behavior. The new viewport-control case passes independently.

Scope

This PR is limited to shared PTY viewport ownership and layout recovery. It does not include mobile navigation controls, terminal input persistence, bounded history streaming, response viewing, repository browsing, or session lifecycle caching.

[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.