feat: add Octokit retry and throttling plugins for resilient API calls

[Leundai]

Summary

This PR adds official Octokit plugins for automatic retry and rate limit handling, making our GitHub API interactions more resilient to transient failures.

Changes

Dependencies

• Added @octokit/plugin-retry (^6.0.0) - Automatic retries for 5xx errors and network failures
• Added @octokit/plugin-throttling (^8.0.0) - Graceful rate limit handling

Configuration

Retry Plugin:

• Automatically retries on 5xx server errors
• Automatically retries on network failures (ECONNRESET, ETIMEDOUT, etc.)
• Configured to NOT retry: 400, 401, 403, 404, 422 (these are not transient)
• Uses exponential backoff by default

Throttling Plugin:

• Handles GitHub rate limits (HTTP 429) gracefully
• Respects Retry-After header from GitHub
• Retries up to 3 times on primary rate limits
• Retries once on secondary rate limits (abuse detection)
• Logs rate limit events for visibility

Why Official Plugins?

Instead of implementing custom retry logic, we chose to use Octokit's official plugins because:

1. Battle-tested: Used by thousands of projects in production
2. Well-maintained: Actively maintained by the Octokit team
3. Handles edge cases: Proper handling of rate limit headers, secondary limits, etc.
4. Less code: Minimal changes to our codebase
5. Future-proof: Will receive updates as GitHub API evolves

Testing

• Lint passes
• Manual testing with rate limit scenarios (optional)

Potential Future Improvements

1. Make retry count configurable: Allow users to configure max retries via manifest config
2. Add GraphQL throttling: Currently only REST API calls go through Octokit; GraphQL has its own retry logic
3. Metrics/observability: Add structured logging or metrics for retry/throttle events
4. Circuit breaker pattern: For extended outages, fail fast instead of retrying repeatedly