Add resilient filesystem error handling with retry logic

[gregpriday]

Summary

Implements automatic retry with exponential backoff for transient filesystem errors to improve reliability on Windows, network drives, and CI environments with high file descriptor pressure.

Closes #29

Changes Made

• Extend RETRYABLE_ERROR_CODES with filesystem errors (EBUSY, EPERM, EACCES, EMFILE, ENFILE, EAGAIN, EIO)
• Add isRetryableFsError() predicate for filesystem-specific error detection
• Create withFsRetry() utility with exponential backoff (100ms, 200ms, 400ms, capped at 2s)
• Implement abort signal support during retry delays
• Cap jitter delays at maxDelay to prevent exceeding limits
• Create fsErrorReport module for centralized error aggregation
• Wrap all fs.readdir(), fs.stat(), and fs.readFile() operations with retry logic
• Add filesystem retry configuration (retryAttempts, retryDelay, maxDelay)
• Add --fail-on-fs-errors CLI flag for strict CI mode
• Display filesystem error summary (retries, successes, failures) after operations
• Add comprehensive unit tests (19 tests) and integration tests
• Record success after retry even when files skipped due to size
• Ensure testPath() respects config and records errors

Implementation Notes

Context & rationale:

• Critical for Windows (antivirus locks), network drives, and CI environments
• Extends existing retry infrastructure (currently only for AI services) to filesystem operations

Implementation details:

• Extended RETRYABLE_ERROR_CODES in src/utils/errors.js with filesystem codes: EBUSY, EPERM, EACCES, EMFILE, ENFILE, EAGAIN, EIO (EACCES added during code review for Windows compatibility)
• Added isRetryableFsError() predicate for filesystem-specific error detection
• Created src/utils/retryableFs.js with withFsRetry() utility implementing exponential backoff (100ms, 200ms, 400ms, capped at 2s)
• Implemented abort signal support during retry delays with proper cleanup
• Created src/utils/fsErrorReport.js for centralized error aggregation and reporting
• Updated src/utils/ignoreWalker.js to wrap all fs.readdir() and fs.stat() calls with retry logic
• Updated src/utils/fileLoader.js to wrap fs.stat() and fs.readFile() with retry logic
• Binary fallback only attempted for non-retryable errors to avoid masking transient issues
• Added config defaults in config/copytree.js: retryAttempts=3, retryDelay=100ms, maxDelay=2s
• Added --fail-on-fs-errors CLI flag to bin/copytree.js for CI strict mode
• Wired error summary reporting in src/commands/copy.js showing retries, successes, failures, and permanent errors
• Exit code 1 set when --fail-on-fs-errors is enabled and failures occur

Breaking Changes & Migration Hints

Breaking changes:

• None - fully backwards compatible with opt-in strict mode

Migration hints:

• New config options: copytree.fs.retryAttempts, copytree.fs.retryDelay, copytree.fs.maxDelay
• New CLI flag: --fail-on-fs-errors for strict failure mode

Follow-up Tasks

• ✅ Add comprehensive unit tests for retryableFs.js and fsErrorReport.js (completed)
• ✅ Add integration tests simulating EBUSY, EPERM, and EMFILE scenarios (completed)
• Consider adding process-wide concurrency semaphore if EMFILE storms persist under heavy load
• Future enhancement: optional copytree.fs.totalTimeoutMs for absolute timeout cap

Code Review Notes

• Conducted collaborative review with Codex
• Fixed abort signal handling during retry delays
• Added Windows EACCES error code to retryable list
• Fixed jitter calculation to respect maxDelay cap
• Ensured testPath() respects config and records errors
• Fixed edge case where recordSuccessAfterRetry wasn't called when files skipped due to size