[Bug]: Paired remote runtime (orca serve) composites stale rows over the current frame in agent TUI panes; resize repaints

### Operating system

macOS (both the paired client and the `orca serve` host)

### Orca version

1.4.167

### Details

**Short summary:**
On a paired remote runtime (`orca serve`), a terminal pane running a full-screen agent TUI renders a composited frame: rows from an *earlier* moment of the same session are drawn on top of the current frame, interleaved at character level. The session underneath is healthy — only the rendered frame is corrupt. Forcing a resize (toggling the right side panel) repaints it clean.

This is the same symptom class as #11757 (macOS desktop, closed by #11726) and #12047 (mobile, still open), on a third surface: the **paired remote runtime**. 1.4.167 contains both #11726 and its release gate #11947, so this is not the pre-fix build.

**What happened?**

Connected to a Mac mini running `orca serve` from a second Mac, opened a workspace, and ran Claude Code (full-screen TUI) in a terminal tab. After tab activity, the pane composited two different moments of the session onto the same rows.

The clearest evidence is that semantically unrelated lines share a row. From the captured frame, one row reads:

```
uhttps://support.claude.com/en/articles/…promotional-accesscode, a well-known open source project, or work from your team).
```

That is the model-announcement banner URL and the earlier trust-folder prompt (`…code, a well-known open source project, or work from your team`) drawn into a single row. Another row merges the CLI banner with a shell prompt from before the current invocation:

```
Claude Code v2.1.220a-ops % claude '--dangerously-skip-permissions'
```

And a third shows character-level interleaving of two frames:

```
UYouscanruseluptto50% of yourcweeklyausage limit on Fable 5.
```

Stale rows from before a `/clear` remain visible under the current frame, which is why it reads as one session bleeding through another.

**Expected behavior**

Revealing or returning to a remote-runtime terminal pane should render one coherent frame from the current buffer, the same as a local pane.

**Actual behavior**

The pane composites stale and current rows together until a resize forces a repaint.

**How can we reproduce it?**

Setup, which is certain:

1. On host A, run `orca serve`.
2. From host B, pair to host A's runtime and open a workspace.
3. Open a terminal tab and run a full-screen agent TUI (Claude Code 2.1.220 here).
4. Use the session normally, including at least one full-screen redraw — the captured frame contains a `/clear` and a subsequent `--resume`, and rows from *before* that `/clear` are still composited into the current frame.

**I have not isolated the exact trigger.** The corruption was noticed already present rather than caught at the moment it appeared, so I can't yet say whether it needs a tab switch, a window focus loss/regain, the pane being hidden and revealed, or whether it can appear without any of those. Given #11757/#7240/#12047 are all reveal-triggered, a hide/reveal cycle is the obvious first thing to try, but I'm not asserting it.

What is reliable: **toggling the right side panel repaints the pane clean.** That resize-heals property is the reproducible part, and it's what places this in the stale-frame class rather than actual stream corruption.

I don't have a scripted oracle yet. Happy to bisect the trigger and come back with tighter steps if that would help triage — I have the setup standing.

**Anything else that might help:**

*Why this looks like an uncovered surface rather than a regression of #11726*

#11726's own reliability contract lists the residual gap explicitly:

> Live Linux, Windows, WSL, SSH, remote-runtime, and mobile-provider journeys remain unproved.

#12047 already demonstrated one of those gaps is real (mobile still reproduces post-fix). This report is the remote-runtime entry in the same list.

*Code paths that differ on this surface* (offered as leads, not as a root-cause claim — I have not proved which one is responsible)

- `src/renderer/src/components/terminal-pane/terminal-hidden-view-parking.ts:53-62` — remote-runtime and SSH PTYs are structurally excluded from the snapshot-backed park/rehydrate path, because parking relies on a daemon model snapshot they don't have. So a remote pane's hide/reveal lifecycle is not the path #11726 hardened.
- `src/renderer/src/lib/pane-manager/mobile-fit-overrides.ts:1-4` — on a shared PTY, non-owners park xterm at another party's authoritative grid rather than fitting locally.
- `src/renderer/src/components/terminal-pane/remote-desktop-viewport-claim.ts:15-21` — reclaiming the viewport requires `paneVisible && documentVisible && documentFocused` *and* a geometry or grid change. A pane revealed without one of those keeps rendering against a grid it doesn't own. This is consistent with resize being the reliable recovery: a resize is what satisfies the claim predicate.
- `src/renderer/src/components/terminal-pane/pty-connection.ts:4044-4053` already names this failure shape in a comment — a PTY pinned at a stale width "pinning `process.stdout.columns` forever and garbling TUIs."

*Ruled out*

Not #9156 (host and paired viewer both auto-answering terminal queries). That mechanism leaks literal escape-sequence text into the input line and would not be healed by a resize; this frame heals completely on resize, and no stray `^[[…R` / `]11;rgb:…` fragments appear.

*Related*

- #11757 — same symptom, macOS desktop, closed by #11726
- #12047 — same symptom, mobile surface, open
- #7240 — same symptom, Windows + Claude Code, open
- #9115 — same symptom class on macOS window refocus, open
- #8396 — separate `orca serve` width issue, open

**Screenshots:**

Captured frame (cropped; paths, repo slug, commit message, and session id redacted). The load-bearing rows are the merged banner/prompt row, the `UYouscanruseluptto50%` interleave, and the `…promotional-accesscode, a well-known open source project…` row where two unrelated lines share one row.