`/resume` picker: sessions older than the 50 most recent are unreachable in the UI; recovering them requires grepping transcript files for the session UUID

Problem Statement

The /resume session picker loads only the 50 most recent sessions (header shows "Resume session (1 of 49)", i.e. 50 minus the current one), and the type-to-search filter only searches this loaded subset, not all sessions on disk. Both the in-session /resume picker and the standalone claude --resume picker are affected; each lists only the 50 most recent sessions. Verified on v2.1.233 (Linux): a month-old session whose AI-generated title contained the search term was not findable in the picker; after bumping the session file's mtime into the top 50, the identical search found it immediately.

This interacts badly with cleanupPeriodDays: I set it high (3650) precisely so old sessions are retained, but retention is not enough. Once a session ages out of the top 50 there is no way to browse to it or search for it in the UI, even though the transcript sits on disk.

The only recovery path today is manual archaeology: grep through ~/.claude/projects/<project>/*.jsonl for remembered prompt text or a title, extract the session UUID from the matching filename, and run claude --resume <session-id> (which works for any session on disk). Session UUIDs are internal identifiers users never see in normal use, so needing grep to find one is a rough edge.

Proposed Solution

Any of these would resolve it, roughly in order of preference:

1. A setting to raise the limit, e.g. resumeSessionLimit, analogous to how cleanupPeriodDays already makes retention configurable.
2. Make picker search cover all sessions on disk, not just the loaded 50 (lazy-load matches on demand).
3. Pagination / "load more" beyond the initial 50.

Prior history

This has been requested repeatedly: #24435 -> #24777 -> #29052 -> #35698 (auto-closed as duplicates of each other), plus #25130, #25729, #38317 (auto-closed as stale). All are locked, and no maintainer response appears on any of them. The consolidated report #26123 did lead to a partial fix in v2.1.47 (picker limit raised from 10 to 50), which shows the limit is adjustable. This request is to make it configurable or unnecessary, since 50 still cannot cover long-lived projects. Filing fresh as the lock messages instruct.