Retry configuration: FileConfig + Manager default

[plutopulp]

Retry configuration: FileConfig + Manager default

Summary

Enable retry configuration at both per-file (FileConfig.retry_config) and manager-default levels, following the established hash_config pattern. Currently FileConfig.max_retries exists but is dead code (never wired through to workers), and there is no manager-level retry configuration at all.

Current State (Problems)

1. Dead code: FileConfig.max_retries field exists (default 0) but is never used:

   • Pool calls worker.download() without passing max_retries
   • Worker calls retry_handler.execute_with_retry() without the optional max_retries parameter
   • RetryHandler uses its construction-time RetryConfig.max_retries (default 3)

2. No manager-level config: Manager constructor accepts HTTP client, queue, tracker, file-exists strategy, etc., but no retry config/handler.

3. Documentation gap: Docs show direct DownloadWorker instantiation with RetryHandler to enable retries, bypassing the manager/pool flow entirely.

Proposal

Replace FileConfig.max_retries: int with retry_config: RetryConfig | None (like hash_config), and add manager-level default retry config.

Design (similar to file_exists_strategy pattern)

# Manager-level default
async with DownloadManager(
    download_dir=Path("./downloads"),
    retry_config=RetryConfig(max_retries=3, base_delay=1.0),
) as manager:
    await manager.add(files)

# Per-file override
FileConfig(
    url="https://example.com/flaky.zip",
    retry_config=RetryConfig(max_retries=5, base_delay=2.0),
)

[plutopulp]

Addressed in #87