[Bug]: Cmd+D split in a paired remote session leaves focus on the source pane #16508

Operating system

macOS 26.5.2 (client) paired to a remote macOS host

Orca version

1.4.178-rc.2 (also read against main @ cac5388545)

Details

Short summary

In a paired remote session (client connected to a remote Orca runtime), splitting a
terminal pane with Cmd+D creates the pane but leaves keyboard focus on the source
pane. The same shortcut on a local workspace focuses the new pane immediately.

What happened?

Local: Cmd+D → new pane appears and is focused; typing goes to it.
Remote: Cmd+D → new pane appears, focus stays on the pane I split from. I have to
click the new pane before typing there. This reproduces every time, not intermittently.

How can we reproduce it?

1. Pair the client to a remote Orca runtime (remote server mode) and open a workspace on it.
2. Open a terminal tab on the remote workspace.
3. Press Cmd+D (split right).
4. Type immediately.
5. The keystrokes land in the original pane. Repeat step 3–4 on a local workspace and
   they land in the new pane.

Expected behavior

A split created by shortcut, context menu, or pane header focuses the new pane, on
remote workspaces exactly as it does locally.

Actual behavior

The new remote pane is created unfocused; the source pane keeps focus until the user
clicks the new pane.

Additional context

This is not the same defect as #13813. That issue is analysed as a local timing
race (an unconfirmed cwd pushes the split behind a lsof await, so fast typing beats
the focus call). The remote path never reaches that code at all:

terminal-pane-split-with-inherited-cwd.ts:19 short-circuits before the local split
helper runs —

const ptyId = args.paneTransports.get(args.pane.id)?.getPtyId() ?? null
if (splitWebRuntimeTerminal(ptyId, args.direction, args.source)) {
  return
}

so splitManagedPane's setActivePaneId(newPane.id) (pane-split-close.ts:67) and
newPane.terminal.focus() (:145) never execute for a remote pane. splitWebRuntimeTerminal
delegates to the host over terminal.split and returns; the new pane is materialised later
from the mirrored session-tabs snapshot.

On that mirrored path the focused pane is whatever layout.activeLeafId says.
TerminalPane.tsx:1478-1486 applies it after the host-authoritative insertion:

const activePaneId = restoredLayout.activeLeafId
  ? manager.getNumericIdForLeaf(restoredLayout.activeLeafId)
  : null

and chooseRemoteTerminalLayout (web-session-tabs-sync.ts:975-990) computes that value with
requestedActiveLeafId first, then the client's existing activeLeafId, and only then the
host's surface.isActive. requestedActiveLeafId comes from a client-recorded focus intent —
the mechanism createWebRuntimeSessionTerminal uses at web-runtime-session.ts:465
(recordWebSessionFocusIntent(intentOwner, worktreeId, createdTabId, createdLeafId)).

splitWebRuntimeTerminal records no such intent, so the existing activeLeafId — the pane
that was split — always wins and focus never moves. The intent ordering is deliberate
(#5435: status-echo snapshots must not steal focus), so the fix belongs on the split
initiator, not in the snapshot precedence.

The split RPC result (RuntimeTerminalSplit) carries handle, tabId and paneRuntimeId
but not the new pane's leafId, which is what a focus intent needs to name the surface.

Related: #13813 (local shortcut split focus), #12227 (stale active-pane state),
#12665 (tab-switching shortcuts inert in remote server mode until a tab is clicked).