Bug: Excessive parallel `wc -l` processes cause CPU saturation on startup (v0.83.0)

[jcashell1989]

Description

When sidecar starts or refreshes, it spawns 20+ concurrent wc -l processes to scan project directories. On an 11-core machine, this causes severe CPU saturation and system load spikes that exceed available resources.

Steps to Reproduce

1. Install sidecar v0.83.0
2. Configure sidecar to monitor 4+ projects
3. Launch sidecar or trigger a refresh
4. Observe system load and process list within first 10 seconds of startup

Expected Behavior

• Sidecar should scan project directories with minimal CPU impact
• System load should remain within reasonable bounds (≤ number of CPU cores)
• Scanning should use sequential or limited-concurrency file operations

Actual Behavior

• 20+ wc -l processes spawn simultaneously within seconds of startup
• System load spikes to 44.6 (1min), 135.6 (5min), 103.7 (15min) on 11-core machine
• Swap utilization hits 93%
• Disk reads sustained at 60 MB/s
• Processes clear only after scanning completes (~30-60 seconds)
• System remains unresponsive during this period

System Information

• sidecar version: 0.83.0
• OS: macOS Darwin 26.4.1
• Architecture: arm64
• CPU cores: 11
• Monitored projects: 4 (mix of local and ~/Documents/ paths)
  • Two projects are large: ~33,000 files and ~16,000 files respectively
  • Two projects are small: ~500 files and ~100 files

Monitoring Evidence

System monitoring (Glances) during the event:

• CPU_TOTAL culprit: wc process
• LOAD culprit: sidecar process
• All wc -l processes ran as same user
• All processes started within seconds of each other

Suggested Fix

1. Throttle concurrent wc calls: Limit to 2-4 concurrent processes instead of spawning all at once
2. Single-pass scanning: Replace multiple wc -l invocations with a single find + wc pipeline per project
3. Async/background scanning: Defer expensive line-count operations until after startup completes

Impact

Sidecar is unusable during the initial startup window on systems with multiple monitored projects, particularly on machines where CPU or swap resources are already constrained.