ui: fix mobile input and viewport, improve scroll & selection

[arthyn]

Bumps xterm to ^5.3 to fix mobile input, fixes scrolling and keyboard avoiding so that you can see the actual prompt. On desktop fixed the issue preventing normal text selection, it just works now!

Obvious claude assistance. The main issue you might have is that this removes this chunk:

    //  start mouse reporting
    //
    term.write(csi('?9h'));

Since we don't have too many dojo apps that use click events I feel like its fine.

Mobile layout fixes:

• viewport meta gets interactive-widget=resizes-content so the layout viewport shrinks when the soft keyboard opens
• body/#root pinned via position: fixed and a --app-height CSS var driven off window.visualViewport.height, so the page can no longer pan beneath the keyboard
• Buffer subscribes to visualViewport.resize so xterm refits when the keyboard shows/hides

UX:

• bumps font to 16px
• enables native text selection (user-select: text) on the rendered rows
• stops emitting X10 mouse reporting (csi('?9h')) on session init; it broke desktop drag-select and swipe-scroll. Apps that need it can request it themselves via blits.
• selection highlight uses a translucent overlay so text remains readable through the highlight
• on touch devices, auto-copies xterm's selection (e.g. on double-tap word select) to the system clipboard

API churn from the xterm 5 upgrade:

• bellStyle: 'sound' / bellSound removed → use term.onBell to play the existing bel.ts sample
• selection theme key renamed to selectionBackground
• rows/cols moved from ITerminalOptions to ITerminalInitOnlyOptions

[Fang-]

stops emitting X10 mouse reporting (csi('?9h')) on session init; it broke desktop drag-select and swipe-scroll. Apps that need it can request it themselves via blits.

As discussed out of band, there is no blit for toggling mouse mode. It's purely client-side.

My understanding is text selection "just works" with the caveat that you have to know to hold the option key, which I believe is relatively standard across terminal emulators, and is mentioned in the info blurb. But we've also seen a large amount of "how do I select text" questions, so "rtfm" may not be an acceptable answer.

As a compromise, we should probably remove mouse mode only on the default session (which is always drum/hood, whose mouse interactivity is limited to moving the cursor in the prompt), and leave it enabled in other sessions/tabs. That way, TUI developers can still experiment with mouse-based interactions.
(Surely one of these days we'll have it in the runtime, too...)

As related polish we may only want to show the info (i) in the top-right when a non-default tab is selected...