fix(terminal): partial-history notice only when there is history to load

[Ark0N]

When a terminal replay is cut short, the web UI shows a bar over the top of the terminal: "Showing the most recent 1.0 MB of this session. 4.8 MB more may still be retained." with a Load full history button (#258). This PR makes that bar appear only when it means something and only when you are looking for history. Before, it showed on almost every tab switch and could not be acted on for fullscreen Claude sessions.

What was wrong

• It showed on almost every tab switch. Every tab switch after a session's first load replays a 1 MiB tail of the session's output stream. Any session that has run for a while has more than that, so the replay is "truncated" and the bar appears. Its × only lasted until the next switch.
• For fullscreen Claude it promised history that does not exist. truncated measures the server's raw byte stream. Load full history asks tmux for its scrollback instead. A fullscreen Claude pane lives in the alternate screen and tmux keeps 0 lines of scrollback for it (Claude keeps the conversation itself). So the "4.8 MB more" was old screen redraws, and the button could only end in the existing downgrade refusal ("Earlier output is no longer kept").

What this PR changes

1. Server reports what a full pull can return. capturePaneBuffer already runs one display-message for the cursor and pane size. That same call now also reads #{history_size} (no extra tmux call). GET /api/v1/sessions/:id/terminal returns it as paneHistoryLines, the rows tmux holds above the visible frame. The field is absent when the body is not a pane capture. This is an additive response field.
2. No notice when there is nothing to load. paneHistoryLines === 0 hides it in every state. A positive count replaces the misleading byte figure: "99,971 lines of scrollback are retained." Without the field (an older server, or a byte-history fallback) the old wording is kept.
3. The notice is lazy.
   • It appears once a wheel or touch gesture reaches the top of the browser buffer, after the history pull that gesture already starts has finished. So it describes what the pull left, not the state it is about to replace.
   • It leaves when a downward gesture is back at live output, or on a tab switch.
   • The × now sticks for that session until the page reloads.
4. formatHistoryBytes no longer prints "1024 KB" for a tail cut just under 1 MiB.

Not changed: what any load fetches or replays, the downgrade guard, the tile grid, and shell pull sizes.

Evidence

Measured on a live instance with 11 fullscreen Claude sessions:

• Every pane: alternate_on=1, history_size=0.
• Tab-switch tails cut 1.2 to 6.2 MB streams down to 1 MiB.
• full=1 returned 0.9 to 5.6 KB, which is the visible frame only.
• Replaying one tail into a headless xterm gave 450 non-blank scrollback rows, of which only 44 were different (one row appeared 33 times).

End to end in Chromium on an isolated instance, with trusted wheel events:

• Shell with ~100k lines of tmux history: hidden after the tab load, shown at the top with the line count and the button, hidden again at the bottom, shown again at the top, and gone for good after ×.
• Pane set up like fullscreen Claude (alternate screen, history cleared, 4.7 MB stream, full=1 = 155 bytes): never shown, even at the top.

Why history_size and not alternate_on

A shell running less is also in the alternate screen, but tmux still keeps its whole history (measured 99,972 rows), and full=1 returns all of it. history_size is exactly what the full pull can add, so the decision keys on that.

Reviewing the diff

About 330 of the 561 added lines are tests and about 20 are docs. The logic is roughly 110 lines:

• src/tmux-manager.ts: queryPaneCursor parses an optional fifth field, validated on its own so a bad value never voids the caret; capturePaneBuffer copies it to opts.capturedHistoryLines.
• src/web/routes/session-routes.ts: one response field.
• src/web/public/constants.js: computeHistoryTruncationNotice gating and wording.
• src/web/public/app.js: banner render gate, sticky ×, _setHistoryNoticeRevealed, and the reset in selectSession.
• src/web/public/terminal-ui.js: _maybeLoadMoreHistoryOnScroll reveals at the top and retires at the bottom.

New test: test/history-notice-reveal.test.ts runs the real app.js / terminal-ui.js / constants.js methods in a vm against a stub DOM. Removing the reveal gate makes 5 of its tests fail.

Risk

• Only scroll gestures reveal the notice (wheel, touch, smooth-scroll frames). These are the same hooks that already trigger the history pull. Dragging xterm's scrollbar to the top does not reveal it, just as it does not trigger the pull today.
• A shell user who relied on the bar showing at load now has to scroll up to see Load full history. That is the intended trade.

Testing

• npm test (the CI gate): 10,376 passed.
• typecheck, lint, format:check and check:frontend-syntax clean.