Performance: Parallelize session switch + message pagination

Problem

Switching between sessions in the web UI is noticeably slow, especially for long conversations. The delay comes from four serial bottlenecks:

1. Expanded-dir pre-fetch — restored expanded directories are fetched one-by-one in a for...of + await loop
2. highlightCode blocks loadDir — the CPU-bound Prism.js pass runs before the network fetch for directory listing is dispatched
3. Git info subprocesses — status, rev-list --ahead, rev-list --behind run sequentially via subprocess.run
4. Full message payload — every session switch serializes and sends the entire message history (100–450+ messages, up to 86KB gzip), even though the user only sees the last ~30 messages on screen

Changes

Commit 1: 671ca99 — Parallelize serial bottlenecks

Commit 2: 1a805d2 — Tests for parallelization

• 6 tests proving Promise.all usage, idle-path ordering, ThreadPoolExecutor adoption, and wall-clock speedup via threading.Barrier

Commit 3: 0ef1de0 — Message pagination (biggest win)

Expected impact

For a remote deployment switching to a 200+ message session: ~800ms → ~40ms.

Compatibility

• undo/retry — use DELETE /api/session/messages/last API endpoint, not frontend S.messages. After reload they reset _messagesTruncated.
• compress — preflight already fetches full session; resets truncation state.
• export — server-side JSON generation via /api/session/export, independent of frontend message array.
• search — can call _ensureAllMessagesLoaded() before searching.
• Backward compatible — omitting msg_limit returns all messages as before.

Tests

19 new tests, all passing:

• TestLoadDirParallelPrefetch (2) — Promise.all usage in workspace.js
• TestLoadSessionIdleOverlap (1) — loadDir dispatched before highlightCode
• TestGitInfoParallel (3) — ThreadPoolExecutor, Barrier-based concurrency proof, wall-clock speedup
• TestMessagePaginationBackend (7) — tail slicing, cursor paging, truncation flag, payload reduction
• TestMessagePaginationFrontend (6) — msg_limit in API call, truncation tracking, scroll-to-top, indicator

All 2,575 existing tests pass (5 pre-existing failures unrelated to this PR).

Great performance work, @jasonjcwu! The author's comment gives a thorough breakdown — adding some review notes here:

Parallelization changes (commits 1–2) look well-targeted:

• Promise.all() for expanded-dir pre-fetch is a straightforward N×RTT → 1×RTT win
• Overlapping loadDir with highlightCode on the idle path is safe as long as DOM mutations don't conflict — the ordering test is a good guard here
• ThreadPoolExecutor(max_workers=3) for the three git subprocess calls is the right tool; the threading.Barrier concurrency proof in tests is convincing

Message pagination (commit 3) is the most impactful change and deserves a close review:

• The _ensureAllMessagesLoaded() escape hatch for undo, compress, and search is the right pattern — avoids breaking those operations on truncated history
• Scroll-to-top trigger for _loadOlderMessages() is a natural UX
• The backwards-compatible msg_limit parameter (no param = full history) is important for external callers

One thing worth verifying in review: the _messages_truncated flag reset behavior on loadSession() — if someone switches sessions while _loadOlderMessages() is in flight, the async prepend should not land on the newly loaded session. The 19-test suite covering pagination backend + frontend is a strong start; confirming session-switch cancellation safety would make this solid.

The ~800ms → ~40ms expected improvement for remote deployments is a meaningful UX gain.

Hold -- Pagination UX Needs Review Before Merge

Placing this PR on hold pending a UX decision on the new message pagination behaviour. Details below.

Approved Changes

The parallelization work looks clean and is approved:

• Promise.all for directory fetches -- straightforward win, no concerns.
• ThreadPoolExecutor for git info -- well-scoped, correct error handling.
• Overlapping loadDir with highlightCode -- good use of concurrency; the sequencing looks safe.

These changes can land as-is once the UX question below is resolved.

Hold Reason -- Message Pagination UX

The decision to limit displayed messages to the most-recent 30 on every session switch, with a "click to load older" / scroll-triggered load path, is a meaningful UX change that affects every conversation view. It needs explicit sign-off before merge.

Questions for @aronprins

1. 30-message tail window -- Is 30 the right default? Should this be user-configurable (e.g. a setting in preferences) or is a fixed window acceptable? For users with long conversations this is the new first-load experience, so the number matters.

2. "Click to load older" indicator -- Is the current placement (top of the message list) and wording final? Should it be a button, an inline sentinel, or a sticky banner? Does it need a loading spinner while older messages are fetched?

Required Fix -- _messagesTruncated Reset Paths

@author: please audit every code path that reloads or replaces the session message list and confirm that _messagesTruncated is reset to false (or the appropriate initial state) in all of the following:

• Retry -- when the user retries a failed assistant turn
• Undo -- when a message is popped/undone
• Manual compression -- when the conversation is compressed/summarised by the user
• Session reload after error -- when the session is reloaded following a network or server error

If any of these paths leave _messagesTruncated = true from a previous load, the UI will incorrectly show the "load older" indicator (or suppress messages) even when the full history is already in memory.

Next Steps

1. @aronprins weighs in on the 30-message default and the indicator UX.
2. Author confirms _messagesTruncated is correctly reset in all paths above (a short comment or checklist reply here is fine).
3. Once both are addressed, remove the hold label and this is ready to merge.

Thanks!

Merged as v0.50.229 via integration PR #1181 (then batched in #1183). Thank you @jasonjcwu — the parallelization and pagination work are live! 🎉