feat(github): honor rate limit reset headers on API retries

[cleanjunc]

Summary

GitHub returns the exact wait time on a rate limited response through the Retry-After header (seconds) or the x-ratelimit-reset header (epoch seconds). The retry paths in gittensor/utils/github_api_tools.py ignored these hints and waited a short flat or generic interval, so a rate limit window that lasts minutes drained the retry budget and surfaced as a transient failure.

A new reusable helper, github_retry_delay, reads the advertised reset window and decides how long to wait:

• Within the cap (MAX_RATE_LIMIT_WAIT_SECONDS, 300s): wait the advertised window so a single sleep clears the limit.
• Beyond the cap: stop retrying and let a later cycle handle the work, instead of sleeping repeatedly and hitting the API during a window that cannot be waited out.
• No usable header: fall back to the existing backoff (flat 2 seconds for the identity check, exponential backoff for GraphQL).

Both retry sites (get_github_identity and execute_graphql_query) route through the helper, so rate limit timing lives in one place and stays consistent. Header lookups rely on the case insensitive headers that requests exposes, matching the lowercase names GitHub sends.

Related Issues

Closes #1531

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other (describe below)

Enhancement to the existing GitHub rate limit retry handling.

Testing

• Tests added/updated
• Manually tested

Added unit tests in tests/utils/test_github_api_tools.py covering header priority, the x-ratelimit-reset epoch path, the case where the window exceeds the cap, fallback when no header is present, and both retry sites honoring the headers. The full tests/utils and tests/validator suites pass (712 passed). The helper was also exercised against real requests CaseInsensitiveDict headers to confirm GitHub's lowercase casing resolves correctly.

Checklist

• Code follows project style guidelines
• Self-review completed
• Changes are documented (if applicable)