fix: add retry with backoff to _fetch_closed_issues for transient 5xx errors

[t7929375-eng]

Problem

_fetch_closed_issues() in repo_scan.py has no retry logic. A single transient 502/503/504 from GitHub causes the function to immediately break and return partial results, silently losing all issues from subsequent pages.

This is inconsistent with every other API function in the codebase:

• get_pull_request_file_changes — 3 retries with exponential backoff
• get_pull_request_maintainer_changes_requested_count — 3 retries
• execute_graphql_query — 8 retries with backoff
• get_merge_base_sha — 3 retries
• get_github_user — 6 retries

Impact

When GitHub returns a transient 5xx during the issue discovery scan, the validator loses visibility into all remaining closed issues for that repo.

Solution

Add retry logic with exponential backoff (3 attempts, capped at 30s) for 5xx errors and connection exceptions, matching the established pattern. Non-retryable errors (404, 422) still return immediately.

Type of Change

• Bug fix

Testing

• 9 unit tests in tests/validator/test_repo_scan_retry.py:
  • Success on first attempt (no sleep)
  • Retry on 502/503 with eventual success
  • All retries exhausted returns partial results
  • 404/422 return immediately without retry
  • ConnectionError triggers retry
  • Exponential backoff timing verification (5s, 10s)
  • Pagination continues after mid-page retry
• ruff check passes
• ruff format passes
• pyright passes
• All existing tests pass

Checklist

• Code follows project style guidelines
• Self-review completed
• Tests added

cc @anderdc @LandynDev