Describe the bug

Over ACP (copilot --acp --stdio), every page of session/list takes about as long as a scan of the whole session store. With many sessions, following nextCursor to the end takes minutes, so an ACP client either waits minutes for the full list or shows a partial one.

On one machine with 6,660 folders (34 GB) in ~/.copilot/session-state, Copilot CLI 1.0.95 on macOS:

• session/list without cwd returns 4,618 sessions in 93 pages of 50.
• Each page takes about 1.0–1.7 s, whether it's the first page or the 90th.
• Following every page took 172 s, and 131 s again right after in the same process, so nothing is cached between lists.
• A page filtered by cwd also takes about 1 s.
• initialize takes about 0.5 s.

The cost per page doesn't depend on the cursor, which suggests every page reads all sessions, then sorts and slices.

Affected version

GitHub Copilot CLI 1.0.95

Steps to reproduce the behavior

1. Have a few thousand sessions in ~/.copilot/session-state.
2. Start copilot --acp --stdio, send initialize, then session/list with {}.
3. Keep calling session/list with each nextCursor until there is none, and time each request.

Every request takes about the same time; the total grows with the number of pages times the size of the store.

Expected behavior

Each page costs roughly what its own 50 sessions cost. For example:

• Keep the sorted index between pages of one listing, or across listings.
• Stop reading once the page is filled.

Also helpful:

• An updatedAfter-style filter, so a client can fetch only sessions that changed since its last list.
• A larger page size, so the client needs fewer requests.

Additional context

Found while building an ACP client that shows every session on the computer. It now works around this: it shows each page as it arrives, saves the last list, and re-reads only the first pages that changed. A full list still costs minutes of CPU in the Copilot process.