External Session import: 16-per-page paging is the only way to find a session among 1128

[Joob1n]

Problem

The import catalog pages 16 sessions at a time (EXTERNAL_SESSION_PAGE_MAX_ITEMS) and offers one filter, includeArchived. That was proportionate to what the only source produced. It stops being proportionate the moment a second one lands.

Measured on one machine:

source	sessions
Codex	19
Claude Code (#3435)	1128

59×. At 16 per page that is 71 pages of cursor paging to reach a session by scrolling, with no way to say which one you want. A user who knows exactly what they are looking for — by title, or by which project it belongs to — has no way to express it.

This is a consequence of #3435 rather than a pre-existing gap: a Codex-only catalog never had enough rows for paging alone to fail. Filing it separately because the fix belongs to the query surface both sources share, not to either adapter.

Where it belongs

ExternalSessionQuery (packages/core/src/external-session.ts) currently carries:

export interface ExternalSessionQuery {
  cwd?: string;
  includeArchived?: boolean;
}

cwd already exists and already works — it is an exact match, which answers "this project" but not "the project I half remember". A text query would sit beside it and be honoured by each adapter over data it has already parsed.

Scope

• Add a text query to ExternalSessionQuery, matched against the session title and its cwd. Both are already in ExternalSessionSummary, so neither adapter needs to read more than it does now.
• Honour it in both adapters — Codex and Claude Code — so the surface does not gain a filter that silently works for one source and not the other.
• A search field in the import settings page, next to the existing archived toggle.
• Decide where the match runs. Filtering after the page is assembled would search only the 16 rows already fetched, which is worse than no search at all; the query has to reach the adapter, before paging.

Not in scope

Searching message content. Titles and paths are metadata the adapters already hold; content means reading every transcript on every keystroke, and that is a different problem with a different budget.

Refs #3435

[Joob1n]

Claiming this one — it is a consequence of #3435, so it should be mine to carry rather than left for whoever notices the paging next.

Taking it after #3435 lands rather than folding it in. The two changes touch different layers: that PR adds a source, this one changes the query surface both sources share, and reviewing "is this transcript parsing correct" and "is this the right search seam" in one diff gets both a shallower read.

The part I expect to be the actual decision is where the match runs. Filtering a page after it is assembled would search the 16 rows already fetched and quietly miss everything behind the cursor — worse than no search, because it looks like it worked. So the query has to reach the adapter ahead of paging, and that is what the shape of ExternalSessionQuery has to support.