tui: update preflight footer renders overlapping frames #38595

Summary

During a background-service version replacement, the animated update preflight footer rendered overlapping spinner, status, version, logo, and progress-bar frames. The service update continued, but the terminal output became difficult to read and made the startup appear corrupted or stuck.

Environment

• opencode version: 0.0.0-next-16097, replacing service version 0.0.0-next-16088
• OS: Darwin 25.5.0, arm64
• Terminal: WarpTerminal, TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/zsh
• Install/channel: global Bun install, next
• Active plugins: voice.ts; incident logs also loaded cmux-feed.js and cmux-session.js, whose schema warnings were unrelated to rendering

Reproduction

1. Keep a managed background service running on an older OpenCode version.
2. Install or partially install a newer CLI version so the next TUI launch requires service replacement.
3. Launch opencode2 in a TTY.
4. Leave the update preflight on "Starting the new background service" long enough for multiple animation frames to render.
5. Observe the split-footer output while service startup remains pending.

Frequency: observed once during an unusually long, approximately 110-second service startup. A deterministic delay may be needed to reproduce it reliably.

Expected Behavior

The update footer should remain one stable, readable four-row surface for the entire replacement, regardless of how long startup takes. Spinner and progress animation must update cells in place without leaking old frames into adjacent text or terminal scrollback.

Actual Behavior

Frames overlapped and repeated, producing output such as:

█▀▀█ OpenCode is updating from 0.0.0-next-16088 to 0.0.0-next-16097
█  █ ⠇ Starting the new background service
█▀▀█ OpenCode is updating from 0.0.0-next-16088 to 0.0.0-next-16097
█  █ ⠏ Starting the new background service
█▀▀█ OpenCode is updating from 0.0.0-next-16088 to 0.0.0-next-16097
█  █ ⠧pStarting the new backgrounext-16097
▀▀▀▀ ━━━━━━━━━━━━━━━━━━━━·······next-16097
▀▀▀▀ ━━━━━━━━━━━━━━━━━━━━·········· 2/3

The service eventually became healthy and no data corruption occurred.

Additional Context

The preflight uses an OpenTUI renderer configured with screenMode: "split-footer", footerHeight: 4, targetFps: 60, and captured external output in packages/cli/src/services/update-preflight.tsx.

The long wait was caused by a separate one-time database migration. It exposed the rendering problem but is not itself the rendering bug.

This is related to the complexity discussed in #36519. A regression test should hold the preflight at stage 2 for an extended interval and verify that repeated animation frames do not alter surrounding cells or leak into scrollback.