Parallelize session discovery and file-processing loops

[rajbos]

Why

With many supported IDEs (VS Code, Cursor, VSCodium, OpenCode, Crush, Continue, Visual Studio, Claude Code) and potentially hundreds of session files, the initial load and every 5-minute refresh was bottlenecked by fully sequential I/O: every path-existence check, every directory scan, and every file stat+parse waited for the one before it. On machines with many workspaces this added seconds of unnecessary wall-clock time.

What changed

Discovery phase (vscode-extension/src/sessionDiscovery.ts)

All four sequential discovery loops are now parallel:

• VS Code path checks — the 10 pathExists() calls for editor variants (stable, insiders, VSCodium, Cursor, remote paths) now run as a single Promise.all() instead of one-at-a-time.
• Workspace/globalStorage scanning — each found VS Code variant is scanned concurrently, and within each variant all workspace subdirs are scanned in parallel too (was a nested sequential for loop).
• Copilot CLI subdirs — events.jsonl stat checks across all UUID subdirs now run as a single Promise.all().
• Crush projects — each discoverSessionsInDb() call runs concurrently across all known projects.

Loading phase (extension.ts + cli/src/helpers.ts)

Added a small runWithConcurrency<R>(files, fn, limit = 20) worker-pool helper (no new dependencies) that processes up to 20 files at a time. Four sequential loops are replaced:

Method	Change
calculateTokenUsage	Parallel stat + cache lookup
calculateDetailedStats	Parallel stat + cache + details fetch; sequential aggregation
calculateDailyStats	Parallel stat + cache lookup; sequential aggregation
calculateUsageAnalysis	Parallel stat + cache lookup; sequential aggregation
CLI calculateDetailedStats	Same pattern

The two-phase approach (parallel gather → sequential aggregate) keeps all Map/counter mutations on the single JS thread — no races, no locks needed.

Trade-offs

• Concurrency limit of 20 — enough to saturate typical SSD I/O without loading hundreds of large JSONL files into memory simultaneously. Can be tuned if needed.
• Discovery uses unbounded Promise.all() because the counts are small (≤10 paths, ≤N workspace dirs per path) and each operation is a cheap syscall.
• The existing two-layer cache (60s file-list TTL + per-file mtime+size) remains untouched — these changes only speed up the work that still needs to happen on a cache miss or first load.