fix(ui): stop the leftover xterm viewport painting a strip under the terminal (src/styles.css, docs)

[smileygames]

Closes #77

端末の下辺に出ていた横方向の帯と、右端のスクロールバーの矢印を消す。原因は実測で特定した。実際の src/styles.css と index.html の DOM からブラウザ上に採寸用のページを組み、そこで箱を測っている。

原因は .xterm-viewport である。xterm 6 のスクロールは .xterm-scrollable-element が持ち、この要素は誰も測らない空の div として残っているが、xterm 自身のスタイルシートは保守されていない二つの指定を当てたままである——テーマの届かない #000 の塗りと、ネイティブのスクロールバーを 15px 分確保する overflow-y: scroll である。端末の箱は height: 100% で面いっぱいへ伸ばしてあり、xterm が描くのは行の整数倍であるから、行数 × 行の高さ を引いた余りが下辺に残る。そこをこの空の要素が黒で塗っていた。

帯は割り算の余りであり、面の高さとともに動く（実測、600〜900px の窓で 4.44px 〜 14.44px）。新しく生まれたものではなく、#68 が 800px の窓で 6.63px から 14.44px へ動かした。

前提に書かれていた仮説（.xterm-screen が .xterm-viewport より広くなって横のバーが出る）は実測で否定された。.xterm-screen は .xterm-scrollable-element の中にあり、横方向の溢れは無い。補正も壊れていない——fit が測るのは .term であり、桁数と行数は実際に描かれている面と一致する（修正の前後どちらでも 1280×800 の窓に対して 126×23、画面は 960×345）。

制約の確認:

• 端末の使える面積は変えていない（.term は 980.44×359.44 のまま）。
• fitShown の呼び出し口には触れていない。三軸の独立（feat(ui): let the whole UI be scaled from a global setting #66 / feat(ui): give the terminal pane a header with tabs, close and size #68 / feat(ui): let the chat text size be changed #60）にも触れていない。
• resize_pty へ渡す桁数と行数は実際に描かれている面と一致する（126×7.617=960 / 23×15=345、いずれも画面の実寸と一致）。

未確認: WebView2 上の見た目。採寸はブラウザ上の計測ページで行っている。

[smileygames]

自己レビュー結果: PASS

#77 の受け入れ基準に対して差分を確認し、原因の主張を独立に裏取りした。

原因の裏取り

issue の前提に書いた仮説（.xterm-screen が viewport より広くなる）は外れており、実装者が実測で否定している。仮説を潰した上で別の原因に到達しているので、その筋を追認する。

node_modules/@xterm/xterm/css/xterm.css を直接読んで確認した。.xterm .xterm-viewport に background-color: #000（ハードコード）と overflow-y: scroll、そして position: absolute + top/right/bottom/left: 0 が乗っている。.xterm の箱いっぱいに黒い層が敷かれ、その右端に native のスクロールバーが確保される。

.xterm-screen はこの中ではなく兄弟である（lib/xterm.js の生成箇所で、viewport と screen が同じ fragment へ別々に append されている）。したがって screen が描く rows × cell height の下に残る帯だけが黒く見える。実機の見え方と一致する。

インストール済みは @xterm/xterm 6.0.0。スクロールは .xterm-scrollable-element 側にあり、xterm-viewport のクラス名は JS 中に生成箇所の一度しか出てこない。display: none で壊れる経路が無いことを、以下まで見て確認した。

• OverviewRulerRenderer — overviewRuler オプション未使用。かつ canvas は viewport の前に兄弟として挿入されるので、隠しても消えない。
• DomRenderer — _viewportElement.style.height（インラインスタイル）を読む。CSS の display はインラインスタイルを書き換えないため、前後で読み値は変わらない。
• ホイールスクロール — viewport にリスナは付いていない。handleMouseWheel は scrollable element 側。

受け入れ基準

• 測定してから直している — 当て推量の CSS ではない。#68 で 6.63px → 14.44px（800px 窓）へ動いたという数字まで出ており、「#68 以降に見え始めた」という観察と符合する。
• 端末の面積を減らしていない（#77 の制約）— .term は 980.44×359.44 のまま。
• 補正の仕組みを壊していない — fitShown の呼び出し口は無改変。resize_pty の桁数と行数は描かれている面と一致（126×7.617=960、23×15=345）。
• 三軸の独立（#60 / #66 / #68）は無改変。

ついでの掃除

height: 100% のセレクタから .xterm-viewport と .xterm-screen が落ちている。どちらも効いていなかったという理由が書かれており（screen は renderer のインライン height を持つためスタイルシートが届かない、viewport は四辺に位置指定済み）、妥当。

実機未確認

• WebView2 での見え方。実測はブラウザで行っており、実機の webview ではない（docs に記録済み）。
• scrollback のホイールスクロール。 経路上は壊れないことを上記で確認したが、動きそのものは未確認。実機で端末を流したときに追随するかを見ておくのが安全。

次の一手

実行モード auto。この自己レビュー通過をもって squash merge する。リリース種別は patch 相当（観測可能だが、CSS 一行の修正であり構造変更ではない）。