Ctrl-R is delivered to every split pane

[sf-jin-ku]

Summary

When a worktree has multiple split panes, pressing Ctrl-R can be delivered to every pane instead of only the active/focused pane. This is especially visible when multiple Claude Code sessions are running: one inactive pane can receive Ctrl-R and enter a stuck/search-like input state.

Expected

Keyboard input should be routed to the single active Ghostty surface in the key window. Inactive split panes should not forward keyDown, keyUp, or modifier changes to Ghostty.

Actual

performKeyEquivalent already checks that the surface is the window's first responder, but the lower-level keyDown / keyUp / flagsChanged paths did not have the same guard. If those paths are invoked for a stale/non-active surface, that surface can still forward the event to its PTY.

Repro

1. Open a worktree with two split panes.
2. Run Claude Code or another TUI in both panes.
3. Focus one pane.
4. Press Ctrl-R.
5. Observe that the inactive pane can also receive Ctrl-R and become stuck / enter an unintended input mode.

Proposed fix

Guard terminal keyboard input at GhosttySurfaceView so only window.firstResponder === self forwards keyboard events to Ghostty, while preserving windowless initialization/test paths.

[sbertix]

Hey 👋

So the PR is mostly harmless (I'll comment it separately), but are you actually able to replicate this issue on the last build from main (update channel "Tip")? 🤔 @sf-jin-ku could you send a video, please?
Cause I can't see how this can happen and I haven't been able to replicate this at all 🥺

1. AppKit sends keyDown: only to the window's single first responder. One pane gets it. Not a broadcast.
2. performKeyEquivalent: this is the only mechanism that fans a keyDown out to every pane, because AppKit walks the whole view tree calling it on each view before delivering the key. This was the real broadcast vector. Fix ⌘⌫ archive hotkey when clicking a sidebar worktree #264 gated it. Since then, only the focused pane forwards. Not a broadcast.
3. Local event monitor matches [.keyUp, .leftMouseDown] only, and localEventKeyUp bails immediately on anything without .command. ⌃R is control, not command, and it's a keyDown anyway. It can't carry it.