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. If this happens on a high-weight repo early in the scan, miner-authored issues are silently missed, incorrectly reducing their solved_count and issue_credibility.

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 without retry.

Type of Change

• Bug fix

Testing

• ruff check passes
• ruff format passes
• pyright passes
• Self-reviewed

Checklist

• Code follows project style guidelines
• Self-review completed

cc @anderdc @LandynDev