fix: keep boo ui scrollback replay compatible with older daemons

[kylecarbs]

Iterates on #72 (by @BenLocal) so we can land scrollback replay without the upgrade hazard, and adds the integration coverage that PR was missing. #72's original commit is preserved underneath; this branch adds fixes on top, so we can iterate here without blocking on the contributor.

What this changes on top of #72

• Backward-compatible handshake. feat: replay scrollback history to boo ui views on attach #72 widened the attach message to a 5-byte AttachPayload (rows, cols, ui flag). A daemon started by a pre-upgrade binary decodes attach as a strict 4-byte SizePayload and rejects the extra byte, so after upgrading, a new boo ui / boo attach cannot attach to a pre-upgrade session (the client reports lost connection). This swaps the flag-in-payload for a separate ui marker message (type 6) sent right before attach. Attach stays the original 4-byte SizePayload. An older daemon ignores the unknown message type (its handler already has a catch-all) and just attaches the view with no history, i.e. graceful degradation instead of a failed attach.
• No partial-history flash on attach. The daemon seeds a focused view with a history replay then a repaint; the ui renders on a ~15ms timer, so a history large enough to span multiple frames could paint a half-applied frame (partial scrollback) before snapping to the live screen. The viewport is now held blank from attach until the repaint's terminating .screen arrives, then revealed. The reveal is incremental: it invalidates the viewport cache so the held-blank rows are re-serialized from the now-complete screen, but keeps the row-level diff, so only rows that actually changed are written — exactly like a plain attach's first repaint. A full-screen rewrite here would emit every row at once, and a ui whose terminal is momentarily undrained would block on that larger write (the same Darwin PTY buffering fix: capture held prefix command keys via kitty release events #74's restoreTty works around) and wedge its event loop before it read the next key or SIGWINCH. The sidebar/status keep rendering so the switch stays responsive, and the cursor stays hidden while the viewport is blank.
• Integration tests for both directions of the feature: a ui view attaching to a session that already had scrolled-off history pages it in on a wheel-up; a plain attach receives only the visible screen (no history dump).

The core mechanism from #72 (Window.historyReplay, the daemon replaying history to ui views before the repaint) is unchanged.

Verification (Zig 0.15.2)

Check	Result
zig fmt --check	pass
zig build	pass
zig build test	129/129
zig build test-integration	73/73
zig build test-all -Doptimize=ReleaseSafe	pass
CI: ubuntu + macOS + ReleaseSafe + nix + fmt	all green

Cross-version matrix (manually driven over real PTYs):

daemon	client	before this PR	after
new	new ui	history replayed	history replayed
old	new ui	lost connection	attaches, no history (graceful)
old	new attach	ok	ok
new	old client	ok	ok

Full review of #72 and detailed findings

Verdict

The feature is well built and correct. The history reconstruction (serialize scrollback history as styled VT, reset SGR, scroll a full screen so every history row lands in the canvas scrollback before the repaint's erase, then repaint the visible screen) is sound and unit-tested for full-dump equality + viewport-at-bottom. Plain attach correctly stays history-free; alt-screen sessions correctly yield no history.

Findings addressed here

1. Upgrade incompatibility (fixed). New attach payload was rejected by older daemons. Fixed via the out-of-band ui marker so attach stays 4 bytes.
2. Partial-history flash for large scrollback (fixed). Viewport held blank until the attach repaint completes, then revealed incrementally. The incremental reveal also keeps the post-attach write small, so a momentarily-undrained ui cannot block on it — caught on macOS CI, where the existing ui: create and kill and ui: viewport resize tests wedged against a full-screen reveal write under Darwin PTY buffering.
3. No integration test for the feature (added). feat: replay scrollback history to boo ui views on attach #72 only had a window-level unit test; the daemon -> client replay seam and the plain-attach gating were untested. Two PTY integration tests now cover both.

Findings left for a follow-up (non-blocking)

4. Daemon memory. historyReplay serializes the whole history into one allocation per attach (bounded by max_scrollback). Fine in practice; could stream if it ever matters.

Notes

• The anti-flash hold itself is timing-dependent to trigger directly, but the incremental-reveal write path is exercised on every ui attach, including the existing ui integration tests that don't drain the client between steps (where the macOS regression surfaced).
• ghostty-vt APIs used (PageList.getTopLeft/getBottomRight(.history), formatter.Extra.none) confirmed against the pinned ghostty.
• historyTo splitting at max_payload is safe because the client feeds frames in order into a stateful VT parser, so a sequence split across the boundary still parses.

Generated by Coder Agents on behalf of @kylecarbs.