aict grep: parallel worker count should be configurable via --workers flag #3

Description

When running aict grep -r on large codebases, the tool scans files sequentially. This is one of the primary reasons aict grep is ~100× slower than GNU grep or ripgrep. Adding a --workers flag to enable parallel file scanning would significantly improve performance on multi-core systems.

Current Behavior

$ aict grep "func" . -r
# Scans files one at a time in a single goroutine

Proposed Behavior

$ aict grep "func" . -r --workers 4
# Spawns 4 worker goroutines to scan files in parallel

$ aict grep "func" . -r --workers auto
# Automatically sets workers to runtime.NumCPU()

Implementation Notes

• Use a worker pool pattern with a buffered channel for file paths
• Collect results via a separate goroutine that writes XML elements as they're discovered
• Default to --workers 1 (sequential) to maintain current behavior and avoid memory spikes on huge directories
• --workers auto should resolve to runtime.NumCPU()
• Ensure thread-safe result ordering if --sort is used (or document that parallel mode does not guarantee order)

Acceptance Criteria

• --workers <n> flag accepts positive integers
• --workers auto resolves to number of logical CPUs
• Default remains sequential (1 worker) for backward compatibility
• Benchmark shows >2× speedup on a 10k-file codebase with --workers 4
• XML output remains valid regardless of worker count
• Tests cover: single worker, multiple workers, auto, and invalid values (0, -1)