TUI: main-view scrollback corrupts with stale status-line glyphs after returning from an agent transcript while a workflow is running

Bug Description

When a workflow is running (dynamic multi-agent orchestration with a live in-place progress region — phase tree / spinner / token counters that redraw in place), I drill into an agent's transcript sub-view and then navigate back to the main view. If I return while (a) the workflow is still running and (b) the main assistant thread is actively streaming output, the already-printed main-view scrollback gets corrupted:

• Stray colored/highlighted single characters from the live status line (e.g. a v9 label, isolated letters like C / p / e / rt / o) are stamped into the middle of prose words.
• Whole lines are overstruck with strikethrough-looking dashes (box-drawing / horizontal-rule characters redrawn at the wrong row).

It is display-only — content is not lost. Ctrl+L or resizing the window forces a full redraw and repaints cleanly.

Environment Info

• Platform: darwin (macOS 26.5.2, build 25F84)
• Terminal: Apple_Terminal 470.2 (TERM=xterm-256color)
• Version: 2.1.218 (Homebrew)
• Provider: Bedrock

Reproduction

1. Start a workflow with a live progress region.
2. Drill into an agent's transcript sub-view.
3. Navigate back to the main view while the workflow is still running and the main thread is streaming output.
4. Observe corrupted scrollback in the main view (stray status-line glyphs stamped into prose, lines overstruck with dashes).

Reproduced repeatedly. Screenshots to be attached.

Expected

Main-view scrollback text stays intact when returning from a sub-view; the live progress region should not bleed characters into committed scrollback.

Likely cause

Appears to be an incremental/differential renderer issue: on partial redraw the renderer moves the cursor forward (non-destructive) rather than writing spaces to clear cells, so stale glyphs from the prior frame (the live status line) show through. A full redraw (Ctrl+L / resize) writes real spaces and is correct — consistent with that theory.

Notes

• Reproduced on macOS Terminal.app. Similar terminal-rendering-corruption reports exist for other platforms (Windows/ConPTY, WSL2), so this does not appear to be platform-specific.
• Not fixed as of 2.1.218.