proposal(cli): confirmed full redraw so Ctrl+O/Ctrl+T can collapse blocks stuck above the viewport

[me2seeks]

Problem

Follow-up to #1097 / #1134 / #1140. The common Ctrl+O flow still strands expanded blocks:

1. Press Ctrl+O — every tool card in view expands.
2. Cards taller than the terminal push their own heads above pi-tui's live viewport into terminal scrollback (viewportTop grows monotonically).
3. Press Ctrl+O again — only cards whose heads are still inside the viewport collapse. The head-scrolled ones are stuck expanded permanently: scrolling the terminal up and back down changes nothing (native scrollback is invisible to pi-tui, so viewportTop never moves back).

#1140 made this explained — a default flip plus a notice — but only when every candidate is above the viewport. The far more common partial case (some cards collapse, some are stuck) is silent, so the toggle reads as broken. "Readable in scrollback" does not help: the user has already read the content and wants the screen back.

Desired outcome

A second-chance collapse that makes the #1097 tradeoff an informed, per-press choice instead of a permanent strand:

• First Ctrl+O/Ctrl+T press: toggle everything in the live viewport (unchanged).
• If expanded blocks sit above the viewport, the notice names them: "N blocks above the view are stuck expanded — press again within 2s to collapse them (redraws the screen, clears pre-session scrollback)."
• Second press inside the window: one knowingly-triggered full redraw collapses every block and re-anchors the viewport at the tail. Transcript content is fully re-rendered into fresh scrollback, so nothing from the session is lost; only pre-Maka shell scrollback is cleared, and only after explicit confirmation.
• The partial-collapse case stops being silent: when some blocks toggle and some are stuck, say so.

This is option 2 of #1134 ("an explicit redraw command that knowingly trades one scrollback clear for a clean re-render"), which #1140 deferred as a possible orthogonal follow-up.

Implementation note: pi-tui's full-render path (firstChanged < viewportTop → ESC[2J ESC[H ESC[3J) is private and reachable only via width/height changes; this needs a public requestFullRedraw()-style API in @earendil-works/pi-tui (upstream PR or the repo's patches/ mechanism). The Maka-side change is small: toggleAllToolExpansion / toggleAllThinkingExpansion gain an includeOffViewport parameter, and the runner reuses the existing double-press window pattern (DOUBLE_ESCAPE_INTERRUPT_WINDOW_MS).

Alternatives or workarounds

• Today: stuck-expanded content stays readable in terminal scrollback and new output follows the flipped default, but there is no way to reclaim the screen short of restarting the session.
• Non-destructive alternative: the /transcript viewer overlay manages its own scrolling and re-projects from state, so it is not bound by scrollback immutability — it could host its own expansion toggles for reviewing older content. That solves "read old collapsed content" but not "collapse the stuck blocks in place".
• Rejected on fix(cli): a block expanded past the viewport cannot be collapsed again #1134 and still rejected here: clamping expanded rendering to viewport height (regresses full-content-into-scrollback), and letting toggles silently touch head-scrolled blocks (reintroduces the fix(cli): expanding an off-screen block triggers a full redraw that clears pre-Maka scrollback #1097 wipe). The confirmation gate is exactly what distinguishes this proposal from the rejected one.

[me2seeks]

I'm working on this — implementing the confirmed full-redraw collapse described above (second press within a short window triggers one knowingly-accepted full redraw; pi-tui full-render seam + Maka toggle changes).