Put the cursor in the terminal after sending a note

Sending already switched to the target terminal's tab, which looks like it
should be enough: `TerminalView` focuses xterm whenever a terminal becomes
active. But that effect keys off `active`, so it only fires on a *change* —
and the dock's ordinary case is sending to the terminal already on screen.
`setActiveTabKey` writes the key that is already set, nothing changes, no
effect re-runs, and focus stays on the Send button. The note is sitting in the
prompt and the user still has to click the terminal before pressing Enter.

So the send now asks for focus explicitly, through a one-shot request in the
store that `TerminalView` consumes and clears — the shape `pendingHomeTab`
already uses. Clearing is not tidiness: hold the id and the second send to the
same terminal writes a value that is already there, which is precisely the
no-op this exists to fix.

Focus is requested only on success. A failed send toasts and leaves the user
where they are, because there is nothing in the prompt to press Enter on.

The three `TerminalView` tests give focus away after mounting before making
any assertion, so what they observe is the request landing and never the focus
that `active` already grants on mount — which would pass with the feature
absent.

752 tests pass, 62 files.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011YPqHpjV4EL6RNEwrRKqQm

app/src/store/appState.test.ts

@@ -112,3 +112,27 @@ describe("toasts", () => {
     expect(toasts()).toHaveLength(2);
   });
 });
+
+describe("terminal focus requests", () => {
+  beforeEach(() => useAppState.setState({ pendingTerminalFocus: null }));
+
+  const pending = () => useAppState.getState().pendingTerminalFocus;
+
+  it("names the session that should take focus", () => {
+    useAppState.getState().requestTerminalFocus("s1");
+    expect(pending()).toBe("s1");
+  });
+
+  // Consumed once, exactly like `pendingHomeTab`. Without the clear, the
+  // second send to a terminal already holding the request would set the same
+  // value, no state would change, and no effect would re-run — which is the
+  // failure this whole mechanism exists to fix.
+  it("is cleared once consumed, so the same terminal can be asked again", () => {
+    useAppState.getState().requestTerminalFocus("s1");
+    useAppState.getState().clearPendingTerminalFocus();
+    expect(pending()).toBeNull();
+
+    useAppState.getState().requestTerminalFocus("s1");
+    expect(pending()).toBe("s1");
+  });
+});

app/src/store/appState.ts

@@ -144,6 +144,21 @@ interface AppState {
   /** Consumed once by `ProjectHome`, then cleared. */
   pendingHomeTab: { projectId: string; tab: string } | null;
   clearPendingHomeTab: () => void;
+  /**
+   * Ask a terminal to take keyboard focus.
+   *
+   * `TerminalView` already focuses when its tab *becomes* active, which covers
+   * switching to a terminal. It cannot cover being asked to focus the terminal
+   * that is already on screen — nothing changes, so no effect re-runs — and
+   * that is the ordinary case for the notes dock, which sits beside the
+   * terminal it sends to.
+   *
+   * Consumed once and cleared, like `pendingHomeTab`: holding the id would
+   * make a second request for the same terminal a no-op state write.
+   */
+  pendingTerminalFocus: string | null;
+  requestTerminalFocus: (sessionId: string) => void;
+  clearPendingTerminalFocus: () => void;
   closeHomeTab: (projectId: string) => void;
   setActiveTabKey: (key: string) => void;
   cycleTab: (delta: number) => void;
@@ -352,6 +367,9 @@ export const useAppState = create<AppState>((set) => ({
     }),
   pendingHomeTab: null,
   clearPendingHomeTab: () => set({ pendingHomeTab: null }),
+  pendingTerminalFocus: null,
+  requestTerminalFocus: (sessionId) => set({ pendingTerminalFocus: sessionId }),
+  clearPendingTerminalFocus: () => set({ pendingTerminalFocus: null }),
   closeHomeTab: (projectId) =>
     set((state) => {
       const key = homeTabKey(projectId);