[AnthonyRonning]

Application Vim's sidebar row now follows a task you open on another computer, and Vim keys keep working after the switch.

What was wrong

Each paired computer has its own chat screen and sidebar. Opening a task on another computer swaps the window over to that computer's screen. The swap carried the sidebar's search, archive and scroll state, but not application Vim's row. So the screen you switched to kept the row it had when you last left it. Usually that was the task you had just come from, while the task you opened was selected and showing in the main window. It made no difference whether you pressed Enter on the row or clicked it.

The screen you switched to also never took the keyboard focus on a return visit. The focus stayed on the screen it replaced, which is no longer drawn, so Vim keys did nothing until you clicked.

This came in with paired remote access (PR #1170), when each computer got its own screen. The recent sidebar work (PR #1248) didn't touch it. Within one computer, including between its projects, the row already followed the open task.

Fix

• Sidebar::browse_state carries the Vim row with the rest of the browse state. A sidebar names its own computer's tasks as plain task rows and other computers' tasks by computer, so the row travels in the by-computer form. On its own computer it turns back into a plain task row. If the destination doesn't show the row, its selection is left alone.
• The screen swapped in takes the keyboard focus, as it already did on its first visit.

Testing

• test_application_vim_row_follows_a_task_opened_on_another_computer swaps a local and a remote computer's chat screens the way the desktop does. It goes local → remote → local → remote, opening each task with Enter on its sidebar row, then presses k.
  • On master it fails every time (10 of 10 runs). Back on the remote screen, the row is still the local task (Computer(Navigate { computer: None, destination: Task("here") })), and k changes nothing.
  • With this change it passes (100 of 100 runs alone, and 3 of 3 alongside the whole chat suite).
  • The test's computers have no backend, so their rows come from the snapshots alone. The first version let the sidebar read task pages from the fixtures' empty stores. An empty reply removes rows, so it failed on Linux CI (and in 1 of 30 local runs) whenever a reply landed mid-test.
• The application Vim, browse-state and computer tests pass (49 tests matching those filters).
• just ci passes, run by the pre-commit hook with MAPLE_HOOK_FULL=1: format, clippy for every feature set, and all tests (1,053 app tests plus the rest of the workspace).
• Real app on macOS, through the desktop's real screen swap, driven with real keystrokes and clicks. I used a local-only preview patch, not part of this PR, that opens fixture chats for "This computer" (two projects) and a fake paired computer "agent-mac".
  • Before:
    • Enter on a local task in agent-mac's sidebar opened it, but the row stayed on agent-mac's "General Chat Introduction", and j did nothing.
    • Clicking "General Chat Introduction" then opened it on agent-mac while the row stayed on the local "Second Project Planning", which is the reported state.
  • After:
    • The row was on the opened task after every switch, by Enter and by click, in both directions.
    • j moved it right away.
  • Switching between the two projects on "This computer" never swaps screens, and the row followed the opened task there. This change doesn't touch that path.

🤖 Generated with Claude Code